Bądź na bieżąco - RSS

BIND9 w Dockerze jako secondary DNS i cache DNS – schemat działania

28 lutego, 2026 | Brak Komentarzy | Kategoria: Linux, Porady

BIND9 w Dockerze

BIND9 w Dockerze może działać jednocześnie jako secondary DNS (slave) dla Twoich stref oraz jako cache DNS (rekurencja + cache) dla intranetu. Poniżej dostajesz gotowy, praktyczny setup oparty o obraz ubuntu/bind9:latest z konfiguracją w jednym pliku (named.conf) oraz danymi przykładowymi (zanonimizowanymi).

Najważniejsze założenie bezpieczeństwa: rekurencja działa wyłącznie dla zaufanych sieci, żeby serwer nie stał się otwartym resolverem.

Spis treści


Wymagania

  • Docker na serwerze (Linux).
  • Porty 53/TCP i 53/UDP dostępne w sieci, z której pytają klienci.
  • Na master DNS masz włączone transfery stref (AXFR/IXFR) dla secondary.
  • Znasz sieci intranet/VPN, które mają prawo do rekurencji.

Uwaga o anonimizacji: w przykładach używam domen typu corp.example i adresów z puli dokumentacyjnej (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). Podmień na własne.

Katalogi na hoście

Trzymamy na hoście jeden plik konfiguracyjny oraz osobno cache i pliki stref slave.

sudo mkdir -p /srv/bind9
sudo mkdir -p /srv/bind9/cache
sudo mkdir -p /srv/bind9/cache/slaves

sudo nano /srv/bind9/named.conf

named.conf – secondary DNS + cache DNS w jednym pliku

Poniżej kompletna konfiguracja: ACL, rekurencja/caching, forwardery oraz strefy typu slave. Wszystko jest krótkie liniowo i nie „wyjeżdża” poza ramkę.

// /srv/bind9/named.conf
// BIND9: secondary DNS (slave) + cache DNS
// Dane przykładowe (zanonimizowane) – podmień na własne.

acl "trusted" {
    127.0.0.1;
    10.10.0.0/16;
    192.168.50.0/24;
};

options {
    directory "/var/cache/bind";

    // Rekurencja i cache tylko dla intranetu
    recursion yes;
    allow-query { trusted; };
    allow-recursion { trusted; };
    allow-query-cache { trusted; };

    // Forwardery upstream (przykładowe IP)
    forwarders {
        203.0.113.53;
        198.51.100.53;
    };
    forward only;

    dnssec-validation auto;

    listen-on { any; };
    listen-on-v6 { any; };

    auth-nxdomain no;
};

// RFC1918 (standardowy plik w obrazie)
include "/etc/bind/zones.rfc1918";

// ---- Strefy secondary (slave) ----

zone "corp.example" {
    type slave;
    file "/var/cache/bind/slaves/db.corp.example";
    masters { 203.0.113.10; };
    allow-notify { 203.0.113.10; };
};

zone "50.168.192.in-addr.arpa" {
    type slave;
    file "/var/cache/bind/slaves/db.192.168.50";
    masters { 203.0.113.10; };
    allow-notify { 203.0.113.10; };
};

// Domyślne strefy (krótki include zamiast inline’owania długich nazw)
include "/etc/bind/named.conf.default-zones";

// Minimalne logowanie (ciszej)
logging {
    category lame-servers { null; };
    category edns-disabled { null; };
};

Dlaczego tak? To nadal jest „jednoplikowa konfiguracja” w sensie: wszystko, co konfigurujesz (secondary + cache), jest w jednym pliku. A długie, systemowe definicje default-zones zostają w obrazie — dzięki temu unikasz linii, których nie da się sensownie złamać.

Uruchomienie kontenera

Najważniejsze: montujemy tylko named.conf (read-only) oraz katalog cache. Dzięki temu pliki systemowe (named.conf.default-zones, zones.rfc1918, bazy db.*) zostają w kontenerze i nie musisz ich kopiować na hosta.

docker run -d \
  --name bind9-container \
  --restart unless-stopped \
  -e TZ=Europe/Warsaw \
  -p 53:53/tcp \
  -p 53:53/udp \
  -v /srv/bind9/named.conf:/etc/bind/named.conf:ro \
  -v /srv/bind9/cache:/var/cache/bind \
  ubuntu/bind9:latest

Jeśli wolisz Compose:

services:
  bind9:
    image: ubuntu/bind9:latest
    container_name: bind9-container
    restart: unless-stopped
    environment:
      - TZ=Europe/Warsaw
    ports:
      - "53:53/tcp"
      - "53:53/udp"
    volumes:
      - /srv/bind9/named.conf:/etc/bind/named.conf:ro
      - /srv/bind9/cache:/var/cache/bind

Uprawnienia (UID/GID bind)

Secondary zapisuje pliki stref do cache. Jeśli brakuje praw, zobaczysz błędy typu „permission denied”. Sprawdź UID/GID użytkownika bind w kontenerze i ustaw właściciela katalogu cache na hoście.

docker exec -it bind9-container id bind

Przykład (u Ciebie może być inny):

uid=101(bind) gid=101(bind) groups=101(bind)

Ustaw właściciela (podmień UID:GID z wyniku):

sudo chown -R 101:101 /srv/bind9/cache
docker restart bind9-container

Testy działania

1) Sprawdzenie składni

docker exec -it bind9-container \
  named-checkconf /etc/bind/named.conf

2) Czy strefy slave się pobrały?

ls -la /srv/bind9/cache/slaves
docker logs --since=10m bind9-container

3) Test secondary (autorytatywnie)

dig @192.0.2.53 corp.example SOA \
  +noall +answer

4) Test cache DNS (rekurencja)

dig @192.0.2.53 example.org A +stats
dig @192.0.2.53 example.org A +stats

Tipy i pułapki

  • Nie montuj całego /etc/bind z hosta, jeśli nie kopiujesz plików systemowych —
    wtedy najczęściej „znika” named.conf.default-zones i zones.rfc1918.
  • Zawsze ogranicz rekurencję (allow-recursion, allow-query-cache) do intranetu.
  • Jeśli master wysyła NOTIFY, dodaj allow-notify tylko z IP mastera.
  • Chcesz twardsze bezpieczeństwo? Kolejny krok to TSIG między master ↔ secondary.

G

Tagi: , , ,

Aktualizacja Nextcloud w Dockerze: Nie zapomnij o tym kluczowym kroku!

31 stycznia, 2026 | Brak Komentarzy | Kategoria: Linux, Porady

Nextcloud Docker indeksyPodczas aktualizacji Nextcloud działającego w kontenerach Docker często pomija się jeden istotny element: indeksy bazy danych. Zaniedbanie przebudowy indeksów może powodować spowolnienie działania Nextcloud po aktualizacji. W tym artykule wyjaśniam krok po kroku, jak prawidłowo zadbać o Nextcloud Docker indeksy przed podniesieniem wersji.

To jeden z tych problemów, które trudno uchwycić na pierwszy rzut oka, bo wszystko działa – tylko wolniej. Czasem dochodzą do tego nieoczywiste komunikaty w logach lub w panelu administracyjnym: sugestie dotyczące bazy danych, ostrzeżenia o brakujących indeksach, albo zalecenia „optymalizacji”. W praktyce bardzo często winny jest pominięty krok przed główną aktualizacją: sprawdzenie i dodanie brakujących indeksów w bazie danych (w tym przypadku SQLite) komendą occ.

W tym artykule pokażę:

  • dlaczego Nextcloud potrafi zwolnić po aktualizacji, mimo że „nic się nie zepsuło”,
  • czym są indeksy w bazie danych i czemu mają krytyczne znaczenie dla wydajności,
  • dlaczego aktualizacje Nextcloud mogą wymagać nowych indeksów,
  • jak bezpiecznie wykonać procedurę krok po kroku w Dockerze (linuxserver/nextcloud),
  • co zrobić, gdy komenda zwróci błąd.

Zanim zrobisz większą aktualizację Nextcloud w kontenerze Docker, uruchom occ db:add-missing-indices i dopiero potem przechodź do aktualizacji obrazu. To prosty nawyk, który potrafi oszczędzić godziny diagnozy „dlaczego po update jest wolniej”.

Skąd bierze się spowolnienie Nextcloud po aktualizacji?

Wydajność Nextcloud zależy od wielu elementów: zasobów serwera, konfiguracji PHP, pamięci podręcznej (Redis), silnika bazy danych i sposobu przechowywania danych. Jeśli jednak mówimy o scenariuszu „po aktualizacji było dobrze, a teraz jest gorzej”, to warto zacząć od tego, co aktualizacja zmienia najczęściej: strukturę danych i sposób, w jaki aplikacja odpyta bazę.

Nextcloud rozwija się dynamicznie. Z każdą wersją pojawiają się nowe funkcje, nowe mechanizmy indeksowania plików, dodatkowe metadane, czasem nowe tabele lub kolumny. Nawet jeśli sama migracja bazy przejdzie poprawnie, to po aktualizacji aplikacja może wykonywać zapytania, które wcześniej były rzadkie albo w ogóle nie występowały. Jeśli do tych zapytań brakuje indeksów, baza danych zaczyna wykonywać kosztowne skany, co w SQLite potrafi szybko stać się wąskim gardłem.

Efekt? Użytkownik widzi „czkawkę” w interfejsie, administrator widzi wzrost obciążenia, a w logach — pozornie nic spektakularnego.

Czym są indeksy w bazie danych i dlaczego są kluczowe?

Indeks w bazie danych możesz porównać do spisu treści albo indeksu haseł w książce. Jeśli chcesz znaleźć konkretne nazwisko w 800-stronicowej publikacji, nie czytasz wszystkiego od początku — korzystasz z indeksu, który wskazuje stronę. Podobnie działa baza danych: kiedy aplikacja pyta „znajdź wszystkie rekordy spełniające warunek X”, indeks pozwala szybko dojść do wyniku bez przeglądania całej tabeli.

Bez indeksu baza często musi wykonać tzw. full table scan, czyli przeszukanie całej tabeli. Przy małych danych to jeszcze „jakoś działa”. Ale Nextcloud bardzo szybko generuje duże ilości rekordów: pliki, udziały, wersje, podglądy, informacje o użytkownikach, aplikacjach, logach, aktywnościach, cronach, zadaniach tła… Lista rośnie.

Najważniejsze korzyści z indeksów:

  • Szybsze zapytania SELECT – szczególnie po kolumnach używanych w filtrach i joinach.
  • Mniejsze obciążenie CPU i I/O – mniej pracy dla bazy i mniej odczytów.
  • Stabilniejsza wydajność przy rosnącej liczbie rekordów.
  • Mniej „dziwnych” problemów, gdzie interfejs działa, ale reaguje opóźnieniem.

Oczywiście indeksy mają też koszt: spowalniają część operacji zapisu (INSERT/UPDATE), bo indeks również trzeba aktualizować. Ale w kontekście Nextcloud, gdzie kluczowe są szybkie odczyty i filtrowanie, poprawnie dobrane indeksy są absolutnie fundamentalne.

Dlaczego aktualizacja Nextcloud może wymagać nowych indeksów?

Aktualizacja Nextcloud to nie tylko „nowszy kod w kontenerze”. To także:

  • nowe lub zmodyfikowane tabele,
  • nowe kolumny w istniejących tabelach,
  • zmiany w sposobie, w jaki aplikacja wyszukuje dane,
  • nowe funkcje, które generują dodatkowe zapytania (np. aktywności, udostępnienia, pełnotekstowe wyszukiwanie, integracje).

W idealnym świecie każda migracja bazy danych dodaje wszystko, co potrzebne. W praktyce — zwłaszcza w dużych projektach — zdarza się, że po aktualizacji pojawiają się zalecenia: „Dodaj brakujące indeksy, aby poprawić wydajność”. Nextcloud dostarcza do tego gotowe narzędzie: komendę OCC, która potrafi wykryć brakujące indeksy i je utworzyć.

Jeśli ten krok pominiesz, Nextcloud będzie działał, ale baza może wykonywać znacznie więcej pracy. A przy SQLite — która świetnie sprawdza się w mniejszych instalacjach, ale ma swoje ograniczenia w obciążonych środowiskach — brak indeksów potrafi być szczególnie bolesny.

Wskazówka administracyjna: Jeśli Twoja instancja ma wielu użytkowników, duże biblioteki plików lub intensywne udostępnienia, rozważ migrację z SQLite do PostgreSQL/MariaDB. Ale nawet wtedy komenda dodająca brakujące indeksy pozostaje dobrym nawykiem.

Instrukcja krok po kroku: indeksy SQLite przed aktualizacją Nextcloud w Dockerze

Poniższa procedura zakłada, że używasz obrazu linuxserver/nextcloud i zarządzasz kontenerem standardowo (Docker / docker-compose). Kluczowa zasada: najpierw backup, potem indeksy, dopiero później aktualizacja obrazu.

[GRAFIKA: Schemat blokowy przedstawiający poprawny proces aktualizacji Nextcloud z krokiem „db:add-missing-indices”]
Grafika powinna pokazywać prosty proces w formie flowchartu: (1) Backup → (2) Uruchomienie komendy occ db:add-missing-indices → (3) Aktualizacja obrazu/wersji Nextcloud → (4) Weryfikacja działania i logów. Alternatywnie: zrzut ekranu terminala z wykonaniem komendy i komunikatem o dodanych indeksach.

Krok 1: Zrób pełną kopię zapasową (kontener + wolumeny z danymi)

To jest moment, w którym wielu administratorów „idzie na skróty”, bo „to tylko mały update”. A potem pojawia się problem i nie ma do czego wrócić. Backup przed operacją na bazie danych to absolutna podstawa — nawet jeśli narzędzie jest bezpieczne, zawsze może dojść do:

  • braku miejsca na dysku podczas tworzenia indeksów,
  • przerwania procesu (restart hosta, restart Dockera, awaria zasilania),
  • problemów z uprawnieniami, które kończą się częściową modyfikacją plików bazy,
  • niezgodności w środowisku pośrodku zmian.

Co backupować?

  • Wolumen / katalog z danymi Nextcloud (to, co mapujesz jako /data i zwykle także /config w linuxserver/nextcloud).
  • Plik bazy SQLite – najczęściej znajduje się w obrębie danych/configu Nextcloud (zależnie od Twojego mapowania).
  • Konfigurację kontenera – np. plik docker-compose.yml, zmienne środowiskowe, reverse proxy, cron.

Najprościej: wykonaj kopię katalogów mapowanych jako wolumeny (np. snapshot na poziomie systemu plików, kopia na NAS, tar na zewnętrzny dysk). Jeżeli masz możliwość snapshotów (ZFS/Btrfs/LVM) – to jest świetny moment, by z nich skorzystać.

Krok 2: Uruchom komendę dodającą brakujące indeksy

Gdy backup jest gotowy i kontener Nextcloud działa, przechodzimy do sedna. Oto komenda, którą warto wykonać przed większą aktualizacją:

docker exec -it -u abc nextcloud php /config/www/nextcloud/occ \
db:add-missing-indices

Ta komenda uruchamia narzędzie occ wewnątrz kontenera i zleca Nextcloud sprawdzenie brakujących indeksów w bazie oraz ich utworzenie (jeśli to możliwe). W wielu przypadkach dostaniesz informację o tym, jakie indeksy zostały dodane, albo że nic nie trzeba robić.

Co oznaczają flagi i elementy komendy?

  • docker exec – uruchamia polecenie w działającym kontenerze.
  • -it – to dwie flagi naraz:
    • -i (interactive) utrzymuje wejście standardowe otwarte,
    • -t (tty) przydziela pseudo-terminal, dzięki czemu komenda zachowuje się „jak w normalnej konsoli”.

    W praktyce: bez -it często też zadziała, ale w administracji Nextcloud i pracy z occ to po prostu dobry standard.

  • -u abc – uruchamia polecenie jako użytkownik abc wewnątrz kontenera. W obrazach linuxserver.io aplikacje zwykle działają pod użytkownikiem o takiej nazwie, a uruchamianie occ jako root potrafi skończyć się problemami z uprawnieniami do plików (zwłaszcza w /config i danych Nextcloud).
  • nextcloud – nazwa Twojego kontenera. Jeśli masz inną (np. nc albo nextcloud-app), podmień ją na właściwą.
  • php – uruchamiamy interpreter PHP, bo occ jest skryptem PHP.
  • /config/www/nextcloud/occ – ścieżka do pliku occ w kontenerze linuxserver/nextcloud. To ważne: w zależności od obrazu ścieżka bywa inna, ale dla linuxserver/nextcloud ta lokalizacja jest typowa.
  • db:add-missing-indices – właściwa komenda OCC, która sprawdza i tworzy brakujące indeksy.

Krok 3: Zinterpretuj wynik i upewnij się, że wszystko przebiegło poprawnie

Jeśli wszystko pójdzie dobrze, zobaczysz komunikaty o dodanych indeksach lub informację, że brakujących indeksów nie znaleziono. Warto po tym kroku:

  • rzucić okiem na logi Nextcloud,
  • sprawdzić panel administracyjny (sekcja ostrzeżeń/konfiguracji),
  • odczekać chwilę, jeśli baza jest duża (tworzenie indeksów może trwać).

Dopiero po tej operacji przechodź do standardowej procedury aktualizacji kontenera (pull nowego obrazu, restart, ewentualne migracje).

Co zrobić, jeśli komenda zwróci błąd?

Błędy zdarzają się rzadko, ale warto mieć plan działania. Oto najczęstsze scenariusze i szybkie kroki naprawcze:

  1. Kontener nie działaJeśli docker exec zwraca błąd typu „Container … is not running”, najpierw upewnij się, że Nextcloud jest uruchomiony:
    • sprawdź docker ps,
    • zobacz logi kontenera: docker logs nextcloud,
    • uruchom kontener ponownie i dopiero wtedy wykonaj komendę OCC.
  2. Zła nazwa konteneraGdy komenda wskazuje, że nie ma takiego kontenera, sprawdź nazwę w docker ps i podmień w poleceniu.
  3. Problemy z uprawnieniamiJeśli w logach pojawiają się błędy zapisu lub dostępu do plików, najpierw upewnij się, że uruchamiasz polecenie jako właściwy użytkownik (-u abc). W obrazach linuxserver to zazwyczaj właściwy wybór. Jeśli masz nietypową konfigurację PUID/PGID, sprawdź, czy mapowania wolumenów mają poprawne prawa dostępu.
  4. Błąd ścieżki do OCCJeżeli dostaniesz komunikat, że plik /config/www/nextcloud/occ nie istnieje, możliwe że:
    • używasz innego obrazu niż linuxserver/nextcloud,
    • Twoja struktura w kontenerze jest inna.

    Wtedy wejdź do kontenera i sprawdź, gdzie leży occ:

    docker exec -it nextcloud sh

    a następnie zlokalizuj plik (np. find / -name occ 2>/dev/null) i dostosuj ścieżkę w komendzie.

  5. Sprawdź logi Nextcloud i logi konteneraJeśli błąd jest „aplikacyjny” (np. problem z bazą, lockami, trybem maintenance), zajrzyj do:
    • logów kontenera: docker logs nextcloud,
    • logu Nextcloud (w zależności od konfiguracji zwykle w /config/www/nextcloud/data/nextcloud.log lub analogicznym miejscu w wolumenie).

Uwaga: Jeśli Twoja instancja jest intensywnie używana (wielu aktywnych użytkowników), rozważ wykonanie tego kroku w oknie serwisowym. Dodawanie indeksów potrafi chwilowo zwiększyć obciążenie bazy.

Dlaczego warto robić to regularnie (i czemu „przed aktualizacją” ma znaczenie)?

Możesz zapytać: „Skoro to tylko indeksy, to czemu mam robić to przed aktualizacją, a nie po?”. Dwa powody:

  • Minimalizujesz ryzyko kumulacji zmian. Jeśli po aktualizacji coś zacznie działać gorzej, nie wiesz, czy to wina migracji wersji, nowych funkcji, czy brakujących indeksów. Robiąc indeksy wcześniej, izolujesz zmienną.
  • Zwiększasz szansę na płynny start po update. Po aktualizacji Nextcloud może uruchomić procesy, które natychmiast zaczną intensywnie odpytwać bazę. Jeśli indeksy już są, unikasz „zimnego prysznica” wydajnościowego.

W praktyce to mały rytuał administracyjny, który warto dodać do checklisty. Zwłaszcza jeśli prowadzisz blog techniczny i chcesz promować dobre nawyki: backup, sanity-check bazy, dopiero potem aktualizacja.

Podsumowanie

Wydajność Nextcloud po aktualizacji nie zawsze psuje się spektakularnie. Częściej „siada po cichu”: trochę wolniej tu, trochę wolniej tam — aż w końcu zaczyna przeszkadzać. Brakujące indeksy w bazie danych (także w SQLite) to jeden z najbardziej niedocenianych powodów takiego zachowania.

Dobry nawyk administracyjny wygląda tak:

  1. Backup (zawsze).
  2. occ db:add-missing-indices w działającym kontenerze.
  3. Dopiero potem aktualizacja Nextcloud (pull + restart + weryfikacja).

To prosta procedura, a potrafi realnie poprawić stabilność i wydajność po kolejnych wydaniach.

Twoja kolej

Masz za sobą aktualizację Nextcloud, po której instalacja zaczęła działać wolniej? A może komenda db:add-missing-indices uratowała Cię przed długim wieczorem z logami?

Napisz w komentarzu, jak wygląda Twoja checklist aktualizacji Nextcloud w Dockerze, jakie problemy spotkałeś i jak je rozwiązałeś. Jeśli artykuł okazał się pomocny, udostępnij go komuś, kto też administruje Nextcloud. I jeśli chcesz dostawać podobne praktyczne poradniki – zasubskrybuj bloga, bo regularnie publikuję sprawdzone procedury i rozwiązania „z pola walki”.

G

Tagi: , ,

Portainer nie działa po aktualizacji Dockera – najszybsze rozwiązanie

27 grudnia, 2025 | Brak Komentarzy | Kategoria: Linux, Porady

Błąd Portainer local unreachable po aktualizacji DockeraPortainer nie działa po aktualizacji Dockera – najszybsze rozwiązanie:

Po aktualizacji systemu lub Dockera (szczególnie do wersji Docker Engine 29) wielu administratorów zauważa, że Portainer uruchamia się poprawnie, można się do niego zalogować, ale nie da się zarządzać lokalnym środowiskiem Docker.

W interfejsie Portainera pojawia się wtedy komunikat:

Failed loading environment
The environment named local is unreachable

W tym artykule pokazuję najszybsze i najprostsze rozwiązanie, które pozwala przywrócić działanie Portainera bez cofania Dockera ani systemu operacyjnego.


Dlaczego Portainer przestaje działać po aktualizacji Dockera?

Od wersji Docker Engine 29 demon Dockera wymusza minimalną wersję API na poziomie 1.44. Problem polega na tym, że aktualna wersja Portainer CE wciąż korzysta ze starszej wersji Docker API.

Efekt jest następujący:

  • Docker działa poprawnie
  • Kontener Portainera uruchamia się bez błędów
  • Portainer nie może połączyć się z lokalnym Dockerem

To powoduje, że środowisko local jest oznaczone jako niedostępne.


Najprostsze i najszybsze rozwiązanie problemu

Rozwiązaniem jest obniżenie minimalnej wersji Docker API, którą demon Dockera akceptuje od klientów takich jak Portainer.

Wykonuje się to poprzez edycję pliku konfiguracyjnego Dockera:

Krok 1: Edycja pliku /etc/docker/daemon.json

Na hoście (Debian, Ubuntu, Raspberry Pi OS) otwórz plik:

sudo nano /etc/docker/daemon.json

Jeżeli plik nie istnieje, utwórz go i wklej:

{
  "min-api-version": "1.24"
}

Jeżeli plik już istnieje (np. zawiera data-root), dopisz nową linię, zachowując poprawną składnię JSON:

{
  "data-root": "/var/lib/docker",
  "min-api-version": "1.24"
}

Uwaga: brak przecinka między wpisami spowoduje, że Docker nie uruchomi się.


Krok 2: Restart Dockera

sudo systemctl daemon-reload
sudo systemctl restart docker

Sprawdź, czy Docker działa poprawnie:

docker ps

Krok 3: Restart Portainera

docker restart portainer

Po kilku sekundach odśwież interfejs Portainera w przeglądarce.


Efekt końcowy

Po wykonaniu powyższych kroków:

  • środowisko local w Portainerze staje się dostępne
  • można normalnie zarządzać kontenerami i stackami
  • nie ma potrzeby downgrade’u Dockera

Podsumowanie

Problem z Portainerem po aktualizacji Dockera wynika z niezgodności wersji Docker API, a nie z błędnej konfiguracji kontenera.

Dodanie wpisu:

"min-api-version": "1.24"

w pliku /etc/docker/daemon.json jest obecnie najszybszym i najbezpieczniejszym rozwiązaniem, dopóki Portainer nie wprowadzi pełnej kompatybilności z Docker Engine 29.

G

Tagi: , , ,

OpenVAS w kontenerze Docker

2 grudnia, 2025 | Brak Komentarzy | Kategoria: Linux, Porady
OpenVAS, Docker

Przewodnik po obrazie immauss/openvas

 

OpenVAS (Open Vulnerability Assessment Scanner) to jedno z najbardziej rozpoznawalnych narzędzi open-source do skanowania luk w zabezpieczeniach.
Dzięki konteneryzacji z wykorzystaniem Dockera wdrożenie oraz utrzymanie tego skanera stało się prostsze, bardziej powtarzalne i odporne na problemy
z zależnościami systemowymi. Jednym z najpopularniejszych kontenerowych wydań jest obraz immauss/openvas, który umożliwia szybkie uruchomienie w pełni funkcjonalnego środowiska skanowania na dowolnym serwerze obsługującym Docker.

Czym jest immauss/openvas?

Obraz immauss/openvas to nieoficjalny, lecz aktywnie rozwijany kontener Dockera zawierający kompletną instalację narzędzia OpenVAS/GVM.
Projekt jest regularnie aktualizowany, co zapewnia świeże bazy NVT (Network Vulnerability Tests), środowisko GVM oraz kompatybilność z nowszymi wersjami Dockera.

Najważniejsze cechy obrazu:

  • oparty na aktualnych pakietach GVM,
  • zautomatyzowane pobieranie i aktualizacje baz NVT,
  • gotowy do użycia interfejs webowy,
  • uproszczona konfiguracja oraz start kontenera.

Instalacja i pierwsze uruchomienie

Wymagania wstępne

  • System Linux, macOS lub Windows (z włączonym Docker Desktop).
  • Zainstalowany i działający Docker Engine.

Pobranie obrazu

docker pull immauss/openvas

Uruchomienie kontenera

Przykładowa komenda docker run:

docker run -d \
  --name openvas \
  -p 8080:9392 \
  -v openvas-data:/data \
  immauss/openvas

Opis parametrów:

  • --name openvas — nazwa kontenera,
  • -p 8080:9392 — mapowanie portu interfejsu webowego GVM na port 8080 hosta,
  • -v openvas-data:/data — wolumen zapewniający trwałość danych (konfiguracje, wyniki skanów, raporty).

Ważna informacja — pierwsze uruchomienie trwa długo

Przy pierwszym starcie kontener pobiera pełną bazę testów NVT oraz kompiluje je – operacja ta może potrwać
nawet kilkadziesiąt minut, w zależności od wydajności dysku i łącza internetowego. Jest to zachowanie oczekiwane i
nie należy przerywać tego procesu, jeśli kontener wygląda na zajęty lub logi intensywnie się przewijają.

Dostęp do interfejsu webowego i pierwsze kroki

Po poprawnym uruchomieniu kontenera otwórz przeglądarkę i wpisz adres:

http://[IP_SERWERA]:8080

Domyślny login: admin
Hasło: generowane automatycznie przy starcie kontenera.

Aby wyświetlić wygenerowane hasło, użyj polecenia:

docker logs openvas | grep "Admin Password"

Po zalogowaniu zaleca się natychmiastową zmianę hasła oraz konfigurację podstawowych parametrów systemu,
w szczególności ustawień związanych z kontami użytkowników, polityką haseł oraz dostępem sieciowym do panelu GVM.

Kluczowe funkcje i możliwości OpenVAS/GVM

OpenVAS w wersji kontenerowej oferuje pełny zestaw funkcjonalności środowiska GVM, co pozwala na realizację
kompleksowych procesów zarządzania podatnościami w infrastrukturze IT.

Skanowanie hostów i sieci

  • skan pojedynczego adresu IP,
  • skan całych zakresów adresowych (np. w notacji CIDR),
  • zaawansowane skanowanie z parametryzacją portów, intensywności testów oraz wykluczeń.

Zarządzanie zadaniami skanowania

  • definiowanie zadań skanowania przypisanych do konkretnych celów (Targets),
  • tworzenie harmonogramów skanów cyklicznych,
  • wykorzystanie profili skanowań dostosowanych do różnych scenariuszy (np. szybki skan, pełny audyt).

Zaawansowana analiza raportów

  • eksport raportów do formatów takich jak PDF, XML czy TXT,
  • grupowanie wyników według poziomu ryzyka i rodzaju podatności,
  • śledzenie zmian podatności w czasie, co ułatwia weryfikację efektywności wdrażanych poprawek.

Integracje i automatyzacja

  • dostępne API GVM (GMP), pozwalające na integrację z systemami SIEM, SOAR lub autorskimi narzędziami,
  • możliwość uruchamiania skanów zautomatyzowanych w ramach pipeline’ów CI/CD,
  • współpraca z systemami zarządzania ryzykiem i ticketingiem (np. poprzez integracje pośrednie).

Zalety użycia wersji kontenerowej

Uruchomienie OpenVAS jako kontenera Dockera niesie ze sobą szereg korzyści z punktu widzenia administratorów systemów
oraz zespołów odpowiedzialnych za cyberbezpieczeństwo.

Izolacja środowiska

Kontener zapewnia izolację procesów i zależności od systemu hosta. Dzięki temu instalacja OpenVAS nie wpływa na inne
usługi oraz pakiety zainstalowane w systemie operacyjnym, a ewentualne konflikty bibliotek są znacząco ograniczone.

Łatwość aktualizacji

Aktualizacja środowiska sprowadza się do pobrania nowszej wersji obrazu i ponownego uruchomienia kontenera:

docker pull immauss/openvas
docker stop openvas
docker rm openvas
docker run -d \
  --name openvas \
  -p 8080:9392 \
  -v openvas-data:/data \
  immauss/openvas

Dane (konfiguracje, wyniki skanów, raporty) pozostają zachowane w wolumenie openvas-data.

Przenośność i skalowalność

Kontener można uruchomić na dowolnym serwerze, który obsługuje Dockera — zarówno w infrastrukturze on-premise,
jak i w chmurze. Umożliwia to szybkie tworzenie środowisk testowych, a także skalowanie rozwiązania poprzez uruchomienie
wielu instancji w zależności od potrzeb organizacji.

Brak konfliktów zależności

Tradycyjna instalacja OpenVAS bezpośrednio w systemie bywa wymagająca i podatna na problemy z zależnościami.
Wersja kontenerowa eliminuje konieczność ręcznej kompilacji czy dostosowywania środowiska, ponieważ wszystkie
potrzebne komponenty znajdują się wewnątrz obrazu Docker.

Szybkie i powtarzalne wdrożenie

Wdrożenie OpenVAS za pomocą kontenera Docker może zostać w pełni zautomatyzowane (np. z użyciem Ansible, Terraform
czy pipeline’ów CI/CD), co pozwala na szybkie odtwarzanie środowiska w różnych lokalizacjach lub w razie awarii.

Podsumowanie

Kontener immauss/openvas stanowi wydajne, stabilne i praktyczne rozwiązanie dla specjalistów
cyberbezpieczeństwa, administratorów systemów, zespołów SOC oraz pentesterów. Umożliwia szybkie wdrożenie narzędzia
OpenVAS na dowolnym środowisku, zapewnia efektywną automatyzację skanowania oraz pełną powtarzalność konfiguracji.

Włączenie tego rozwiązania do arsenału narzędzi bezpieczeństwa znacząco ułatwia prowadzenie regularnych, niezależnych audytów podatności, wspiera proces zarządzania ryzykiem oraz pozwala na bieżąco weryfikować stan bezpieczeństwa infrastruktury IT w organizacji.

G

Tagi: , ,

Bezpieczny serwer SFTP w 5 minut? To możliwe z Dockerem i atmoz/sftp!

27 września, 2025 | Brak Komentarzy | Kategoria: Linux, Porady
Serwer SFTP atmoz/sftp

Potrzebujesz szybko uruchomić bezpieczny serwer SFTP w odizolowanym środowisku, bez instalacji dodatkowego oprogramowania na serwerze? Dzięki obrazowi Docker atmoz/sftp jest to możliwe w kilka minut. W tym artykule pokażemy, jak skonfigurować taki serwer krok po kroku oraz jak dostosować go do różnych scenariuszy w praktyce.

Dlaczego warto wybrać atmoz/sftp?

Obraz atmoz/sftp to lekka, gotowa do użycia implementacja serwera SFTP, która działa w kontenerze Dockera. Rozwiązuje typowe problemy administratorów:

  • Izolacja: serwer SFTP działa w kontenerze, minimalizując ryzyko wpływu na system hosta.
  • Łatwa konfiguracja: wystarczy kilka zmiennych środowiskowych, by uruchomić gotowy serwer.
  • Bezpieczeństwo: dostęp oparty na SSH i możliwość ograniczenia użytkowników do wybranych katalogów.
  • Szybkość wdrożenia: w kilka minut można uruchomić działający serwer, bez kompilacji czy skomplikowanej konfiguracji.

Instalacja Dockera

Jeśli nie masz jeszcze zainstalowanego Dockera, możesz to zrobić w systemach Linux za pomocą poleceń:

sudo apt update 
sudo apt install docker.io -y 
sudo systemctl enable --now docker 

Sprawdź, czy Docker działa poprawnie:

docker --version 

Uruchomienie podstawowego serwera SFTP

Poniższe polecenie tworzy prosty serwer SFTP z jednym użytkownikiem:

docker run -p 22:22 -d \ 
-v /host/data:/home/user/upload \ 
-e SFTP_USERS="user:password:::upload" \ 
atmoz/sftp 

Wyjaśnienie parametrów:

  • -p 22:22 – mapowanie portu kontenera na port hosta.
  • -v /host/data:/home/user/upload – montowanie katalogu z hosta jako przestrzeni dostępnej dla użytkownika.
  • -e SFTP_USERS – definiuje użytkowników w formacie login:hasło:uid:gid:katalog.

Praktyczne scenariusze konfiguracji

1. Jeden użytkownik z dostępem do katalogu

docker run -p 22:22 -d \ 
-v /srv/sftp/data:/home/alice/data \ 
-e SFTP_USERS="alice:SuperHaslo:::data" \ 
atmoz/sftp 

Użytkownik alice może logować się i przesyłać pliki wyłącznie do katalogu /home/alice/data.

2. Wielu użytkowników z różnymi katalogami

docker run -p 22:22 -d \ 
-v /srv/sftp/alice:/home/alice/data \ 
-v /srv/sftp/bob:/home/bob/docs \ 
-e SFTP_USERS="alice:HasloAlice:::data bob:HasloBob:::docs" \ 
atmoz/sftp 

Każdy użytkownik ma własny katalog i jest w nim ograniczony (tzw. chroot).

3. Integracja z aplikacją – katalog współdzielony

docker run -p 2222:22 -d \ 
-v /srv/app/uploads:/home/client/shared \ 
-e SFTP_USERS="client:TrudneHaslo:::shared" \ 
--name sftp-server \ 
atmoz/sftp 

Taki scenariusz jest często używany do automatycznej wymiany danych między aplikacjami a partnerami biznesowymi.

Bezpieczeństwo i dobre praktyki

  • Używaj silnych haseł lub – lepiej – kluczy SSH.
  • Uruchamiaj kontener z ograniczonymi uprawnieniami i wyłącz dostęp roota.
  • Regularnie aktualizuj obraz atmoz/sftp do najnowszej wersji.
  • Monitoruj logi kontenera za pomocą docker logs.

Zalety wykorzystania Dockera i atmoz/sftp

Uruchomienie serwera SFTP w kontenerze Dockera pozwala na:

  • Szybkie wdrożenie: pełna konfiguracja w kilka minut.
  • Łatwą migrację: kontener można przenieść na inny host bez zmian w konfiguracji.
  • Bezpieczeństwo: odizolowane środowisko minimalizuje ryzyko podatności w systemie hosta.
  • Skalowalność: łatwo uruchomić wiele instancji dla różnych klientów.

Podsumowanie

Obraz atmoz/sftp to idealne rozwiązanie, jeśli potrzebujesz szybko uruchomić bezpieczny serwer SFTP w odizolowanym i łatwym do zarządzania środowisku. Dzięki Dockerowi wdrożenie jest proste, a konfiguracja elastyczna – od prostych jednoużytkownikowych scenariuszy po integrację z aplikacjami biznesowymi.

G

Tagi: , , , ,

Guacamole – zdalny dostęp w przeglądarce

26 października, 2024 | Brak Komentarzy | Kategoria: Linux, Porady

Apache Guacamole to bezkliencki system zdalnego dostępu, który umożliwia łączenie się z pulpitami zdalnymi poprzez przeglądarkę internetową. Dzięki obsłudze protokołów takich jak VNC, RDP i SSH, pozwala na zarządzanie różnymi systemami operacyjnymi z jednego miejsca, bez konieczności instalowania dodatkowego oprogramowania na urządzeniu klienckim.

W poniższym wideo przedstawiono szczegółowy proces instalacji Guacamole przy użyciu Dockera. Krok po kroku omówiono konfigurację bramki zdalnego dostępu, co umożliwia szybkie wdrożenie tego rozwiązania w środowisku sieciowym. Dzięki temu można efektywnie zarządzać zdalnymi systemami i aplikacjami, co jest szczególnie przydatne w administracji infrastrukturą IT.

Przydatne linki:

G

Tagi: , , , ,

Portainer po aktualizacji Docker 26 – problemy

29 czerwca, 2024 | Brak Komentarzy | Kategoria: Linux, Porady
Portainer Docker 26 - problemy

Wprowadzenie

Niedawna aktualizacja Dockera do wersji 26 spowodowała problemy dla użytkowników Portainera. W tym artykule omówimy na czym polegają te problemy, jakie są ich przyczyny oraz jak można je rozwiązać. Pokażemy również przykłady możliwych działań, aby uniknąć zakłóceń w działaniu systemów.

Problem

Po aktualizacji Dockera do wersji 26, wielu użytkowników Portainera (wersja 2.19.4) zauważyło, że nie mogą wyświetlać szczegółów obrazów ani uzyskiwać dostępu do konsoli kontenerów. Utrudnia to poważnie zarządzanie kontenerami i monitorowanie ich stanu.

Przykłady problemów

  • Brak możliwości przeglądania szczegółów obrazów Docker.
  • Niedziałająca konsola kontenerów, co uniemożliwia wykonywanie poleceń wewnątrz kontenerów.

Przyczyny

Problemy te wynikają z usunięcia niektórych funkcji w Dockerze 26, na których polegała poprzednia wersja Portainera. Zmiany w Dockerze spowodowały, że niektóre API używane przez Portainera przestały działać zgodnie z oczekiwaniami.

Rozwiązania

Tymczasowe rozwiązanie

Jednym z tymczasowych rozwiązań jest cofnięcie wersji Dockera do 25.0.5. Umożliwi to powrót do poprzedniej funkcjonalności, zanim zostanie wprowadzona odpowiednia poprawka w Portainerze.

Aktualizacja Portainera

Zespół Portainera szybko zareagował na zgłoszone problemy i wydał wersję 2.20.1, która naprawia problemy z kompatybilnością z Dockerem 26. Zaleca się aktualizację Portainera do tej wersji, aby uniknąć dalszych problemów.

Jak przeprowadzić aktualizację

  1. Cofnięcie wersji Dockera:
  • Odinstaluj obecną wersję Dockera.
  • Zainstaluj Docker w wersji 25.0.5 z odpowiedniego źródła.
  1. Aktualizacja Portainera:
  • Przejdź do strony Portainera i pobierz najnowszą wersję.
  • Zaktualizuj Portainera do wersji 2.20.1 zgodnie z instrukcjami na stronie.

Przykładowe komendy aktualizacji

# Cofnięcie wersji Dockera do 25.0.5
sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get install docker-ce=5:20.10.5~3-0~ubuntu-focal

# Aktualizacja Portainera do wersji 2.20.1
docker pull portainer/portainer-ce:2.20.1
docker stop portainer
docker rm portainer
docker run -d -p 8000:8000 -p 9443:9443 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:2.20.1

G

Tagi: , ,

Zarządzanie czasem pracy zdalnej: wprowadzenie do Kimai i Docker

27 stycznia, 2024 | Brak Komentarzy | Kategoria: Linux, Porady, Windows

Praca zdalna i prawo: efektywne monitorowanie czasu pracy

W Polsce, w obliczu nowych przepisów prawnych oraz rosnącej popularności pracy zdalnej, pojawiła się pilna potrzeba znalezienia skutecznych metod monitorowania czasu pracy. Zmiana ta wynika z konieczności dostosowania się do przepisów prawa pracy, które wymagają od pracodawców dokładnego rejestrowania czasu pracy pracowników, niezależnie od ich lokalizacji. Rozwiązanie ma na celu zapewnienie ochrony praw pracowniczych i przestrzegania norm dotyczących czasu pracy, co jest szczególnie ważne w modelu pracy zdalnej, gdzie tradycyjne metody rejestracji czasu pracy mogą być nieefektywne lub niewystarczające. Dlatego pojawiła się potrzeba wdrożenia narzędzi umożliwiających efektywne i zgodne z prawem zarządzanie czasem pracy zdalnej. Jednym z proponowanych jest bezpłatna platforma Kimai, która oferuje funkcjonalności konkurencyjne w stosunku do płatnych rozwiązań, takich jak TimeCamp czy Toggl, dostarczając równie efektywnych narzędzi do monitorowania czasu pracy, lecz bez dodatkowych kosztów dla organizacji.

Konteneryzacja Docker: efektywność i bezpieczeństwo

Konteneryzacja za pomocą Dockera stanowi jedną z najbardziej efektywnych metod wdrażania i zarządzania aplikacjami, oferując szereg zalet zarówno na systemach Windows, jak i Linux. Jedną z głównych zalet jest zdolność do szybkiego tworzenia gotowych do użycia serwerów w ciągu zaledwie kilku minut. Docker pozwala na izolację aplikacji w kontenerach, co zapewnia spójność środowiska między różnymi systemami operacyjnymi, eliminując typowe problemy związane z różnicami w konfiguracji. Co więcej, konteneryzacja ułatwia zarządzanie zasobami, umożliwiając efektywniejsze wykorzystanie dostępnej infrastruktury. Istotnym aspektem bezpieczeństwa jest możliwość korzystania z dobrze utrzymywanych i regularnie aktualizowanych obrazów kontenerów, co minimalizuje ryzyko eksploatacji znanych luk bezpieczeństwa. Dzięki temu, wybierając Docker, użytkownicy otrzymują nie tylko szybkie i elastyczne rozwiązanie do wdrażania aplikacji, ale także system, który przy odpowiednim zarządzaniu i wyborze źródeł może oferować wysoki poziom bezpieczeństwa.

Docker-compose: uproszczenie zarządzania wieloma kontenerami

Pakiet docker-compose jest narzędziem ułatwiającym zarządzanie wielokontenerowymi aplikacjami Docker. Pozwala on na definiowanie i uruchamianie aplikacji składających się z wielu kontenerów za pomocą jednego pliku konfiguracyjnego, zwanego docker-compose.yml. Dzięki temu, zamiast uruchamiać każdy kontener osobno i ręcznie zarządzać ich zależnościami oraz siecią, użytkownicy mogą wykorzystać docker-compose do automatyzacji tego procesu. Narzędzie to znacznie upraszcza proces konfiguracji środowiska, zwłaszcza w przypadku skomplikowanych aplikacji, gdzie interakcje między kontenerami są kluczowe. Ważne jest, że docker-compose nie jest domyślnie dołączony w instalacji standardowej wersji Docker i wymaga osobnego zainstalowania w systemie. Jest on dostępny zarówno dla systemów operacyjnych Windows, jak i Linux, a jego instalacja znacząco rozszerza możliwości zarządzania kontenerami Docker, ułatwiając pracę deweloperów i administratorów systemów. W systemie Windows docker-compose jest zwykle instalowany automatycznie wraz z Docker Desktop, a jego aktualizacja odbywa się poprzez aktualizację całego pakietu Docker Desktop.

Instalacja Kimai: konfiguracja via docker-compose

Aby rozpocząć instalację Kimai, pierwszym krokiem jest przygotowanie niezbędnego środowiska, a następnie utworzenie nowego folderu, w którym należy zapisać plik z poniższego przykładu. Jest on kluczowy dla procesu instalacji, gdyż zawiera konfigurację niezbędną do uruchomienia i zarządzania Kimai przy użyciu Docker-compose.

version: '3.5'
services:
  sqldb:
    image: mysql:5.7
    environment:
      - MYSQL_DATABASE=kimai
      - MYSQL_USER=kimai
      - MYSQL_PASSWORD=kimai
      - MYSQL_ROOT_PASSWORD=kimai
    volumes:
      - ./kimai2_db:/var/lib/mysql
    command: --default-storage-engine innodb
    restart: unless-stopped
  nginx:
    image: tobybatch/nginx-fpm-reverse-proxy
    ports:
      - 8080:80
    volumes:
      - public:/opt/kimai/public:ro
    restart: unless-stopped
    depends_on:
      - kimai
  kimai:
    image: kimai/kimai2:latest
    environment:
      - APP_ENV=prod
      - TRUSTED_HOSTS=localhost
      - ADMINMAIL=admin@example.me
      - ADMINPASS=changemeplease
      - DATABASE_URL=mysql://kimai:kimai@sqldb/kimai
      - TRUSTED_HOSTS=nginx,localhost,127.0.0.1
    volumes:
      - public:/opt/kimai/public
    restart: unless-stopped
volumes:
    public:

Żeby spersonalizować konfigurację trzeba zmienić dwa ustawienia zanaczone pogrubioną czcionką. W przypadku adresu e-mail będzie to zarazem nazwa konta do pierwszego logowania. W ostatnim kroku aby uruchomić swoją instancję Kimai i rozpocząć śledzenie czasu otwórz terminal, przejdź do folderu, w którym przechowywany jest powyższy plik, i wykonaj polecenie:

 docker-compose up -d

Po pomyślnym wykonaniu polecenia możesz otworzyć swoją instancję do śledzenia czasu Kimai w preferowanej przeglądarce internetowej i zalogować się przy użyciu danych uwierzytelniających z pliku docker.

G

Tagi: , , ,

Reset hasła administratora – Portainer

29 marca, 2023 | Brak Komentarzy | Kategoria: Linux, Porady
Portainer

Konteneryzacja przy użyciu Dockera jest obecnie jednym z absolutnie topowych tematów. Świat zmierza w kierunku upraszczania i przyspieszania wszelkich operacji więc nikogo nie zdziwi, że do zarządzania Dockerem najłatwiej i najszybciej jest użyć nakładki o nazwie Portainer. Niestety zawodna pamięć ludzka (oraz brak dobrych nawyków) często prowadzą nas na manowce. W konsekwencji może zdarzyć się, że hasło administracyjne do tego ostatniego po prostu nam umknie. Co wtedy zrobić?

Po pierwsze musimy zmierzyć się z konsolą serwera i zatrzymać kontener Portainer:

docker stop "id-kontenera-portainera"

W drugim kroku przystępujemy do właściwej operacji pobierając odpowiednie narzędzie z repozytorium:

docker pull portainer/helper-reset-password

Ostatecznie możemy zeresetować hasło dla konta admin:

docker run --rm -v portainer_data:/data portainer/helper-reset-password

W wyniku działania powyższej komendy powinniśmy otrzymać zestaw niezbędnych informacji:

... Password succesfully updated for user: admin
... Use the following password to login: ****

Zwróćmy uwagę na wyświetlane hasło, które trzeba zapamiętać. Najprawdopodobniej zmienimy je przy pierwszej okazji ale na razie będzie nam potrzebne.

Na koniec używamy poniższego polecenia, aby ponownie uruchomić kontener z Portainerem, a następnie zalogować się przy użyciu nowego hasła.

docker start "id-kontenera-portainera"

Jak wspomniałem podejrzewam, że pierwszą czynnością będzie zmiana hasła i cały cykl znowu może się powtórzyć. 😉

Tagi: , ,

Kopie zapasowe Docker

3 sierpnia, 2022 | Brak Komentarzy | Kategoria: Bez kategorii, Linux, MacOS, Porady, Windows
Kopie zapasowe Docker

Ten temat pojawiał się wielokrotnie we wpisach. Chodzi oczywiście o kopie zapasowe. Ludzie dzielą się na dwie kategorie tych, którzy je robią i tych, którzy je będą robili (truizm, ale trzeba go powtarzać do znudzenia). Tym razem, ponieważ od jakiegoś czasu bardzo popularne są rozwiązania oparte o konteneryzację, parę słów jak to zrobić gdy używamy środowiska Docker.

Oczywiście metodę, o której będzie za chwilę można również stosować np. do migracji całych kontenerów na nowe serwery.

Cała procedura składa się z kilku dosyć prostych kroków. Jedynym wymaganiem jest posiadanie dostępu w wiersza poleceń (konsola). Inna sprawa to mała sugestia, że najlepiej będzie skorzystać ze środowiska Linux (Debian, Ubuntu itp.) do budowy swojego serwera. Jednak w przypadku Windowsów również wszystko powinno działać.

Krok pierwszy to zatrzymanie kontenera, dla którego będziemy tworzyć kopię zapasową:

docker stop nazwa_kontenera

Jeżeli nie wiemy jakiej nazwy użyć lub po prostu otrzymujemy komunikat o błędzie wystarczy sprawdzić wszystkie dostępne kontenery:

docker container ls

W drugim kroku tworzymy obraz naszego kontenera:

docker commit nazwa_kontenera nazwa_kontenera

Ostatni parametr to tak naprawdę nazwa obrazu ale dla uproszczenia przyjmijmy, że jest ona taka sama jak nazwa kontenera.

Trzeci krok to zapisanie obrazu do pliku.

docker save nazwa_kontenera

W tym miejscu należy wspomnieć, że do tego momentu udało się zapisać stan kontenera. Jeśli instalacje, dla których robimy kopie mają zdefiniowane zewnętrzne wolumeny to należy skopiować ich zawartość oddzielnie. Generalnie można to zrobić ręcznie, ale dużo wygodniej będzie skorzystać z gotowego rozwiązania. Warto polecić skrypt docker-volumes.sh. Za jego pomocą dosyć łatwo można zapisać wszystkie stałe dane do jednego archiwum:

docker-volumes.sh nazwa_kontenera \ 
save nazwa_kontenera_wolumeny.tar.gz

Mając kopie zapasową w postaci dwóch plików tj. obrazu kontenera oraz wolumenów jesteśmy zabezpieczeni. Jeśli chcielibyśmy przenieść dane na inne sewery wystarczy skopiować je do nowej lokalizacji.

Ostatecznie na nowym serwerze, po przygotowaniu środowiska Docker, wykonujemy trzy polecenia.

Tworzymy kontener z wykorzystaniem skopiowanego obrazu:

docker create --name nazwa_kontenera \
{zestaw_opcji_uruchomieniowych} nazwa_kontenera

Przywracamy wolumeny:

docker-volumes.sh nazwa_kontenera load nazwa_kontenera_wolumeny.tar.gz

Uruchamiamy kopie kontenera:

docker start nazwa_kontenera

Przy odrobinie szczęścia, w tym momencie powinniśmy cieszyć się kolejną, nową instancją naszej usługi.

MG

Tagi: , ,