📬 ISN 242: Docker run vs start, BNG z zewnętrznym DHCP i automatyzacja Cloudflare Tunnel!

Próżność architekta

The Architect’s Vanity: How I Engineered My Own Technical Debt

I spent six months reading RFCs to build a global RSVP-TE backbone only I could safely operate. The engineers who replaced me ripped it out in a week.

LinkedInHerve Hildenbrand

Herve Hildenbrand spędził sześć miesięcy na czytaniu RFC i budowaniu backbone'u opartego na RSVP-TE. Inżynierowie, którzy go zastąpili, zdemontowali go w tydzień. I mieli rację.

Autor połączył sieci w jeden IGP, dodał MPLS RSVP-TE i ręcznie zaprojektowałem każdy LSP. Deployment był bezbłędny. Tabele routingu – arcydzieło.

I właśnie na tym polegał problem. Traffic engineering działał perfekcyjnie, ale wynik biznesowy był prawie niezauważalny. Zbudował system o wyraźnie wyższej złożoności operacyjnej, który osiągał efekty zbliżone do znacznie prostszego rozwiązania.

Każda zmiana wymagała głębokiego zrozumienia nie tylko projektu, ale intencji stojącej za każdym wyjątkiem. Nie było automatyzacji. Był za to jeden punkt wiedzy: Autor.

Kiedy przeszedł do innej roli, następcy odziedziczyli system technicznie elegancki i operacyjnie kruchy. Wymienili inżynierską perfekcję na coś cenniejszego – zdolność do przeżycia bez autora.

Mam teraz nazwę dla tego rodzaju długu: próżność architektoniczna. To dług, który powstaje, gdy budujesz sieć, którą chcesz projektować, zamiast sieci, której faktycznie potrzebuje biznes.

Trzy pytania, które zadaj sobie przed kolejnym projektem

Zanim zdefiniujesz architekturę, odpowiedz uczciwie:

• Bus factor: Jeśli jutro odejdziesz, czy architektura pozostanie biznesowym aktywem – czy stanie się operacyjnym ciężarem?
• Motyw: Rozwiązujesz realny problem biznesowy, czy dajesz swojej technicznej ciekawości uprawnienia produkcyjne?
• Reguła 3 w nocy: Czy kompetentny mid-level engineer zdebuguje incydent bez dzwonienia do ciebie?

Jeśli odpowiedź na którekolwiek pytanie brzmi „nie" – możliwe, że nie budujesz odporności. Budujesz zależność.

docker run vs docker start

#docker #cybersecurity #sysadmin #devops #itsecurity | Krzysztof Godzisz

Zapewne zwróciłeś uwagę, jak wielu początkujących użytkowników dockera tworzy zduplikowane kontenery, zupełnie nie zdając sobie z tego sprawy. Wpisują komendę, aplikacja działa, ale po restarcie systemu wpisują to samo polecenie i nagle na dysku pojawia się kolejny, identyczny twór. Brzmi znajomo? Problem leży w niezrozumieniu fundamentalnej różnicy między dwoma poleceniami: docker run a docker start. Wszystko rozbija się o cykl życia kontenera. Kiedy wpisujesz w terminalu: docker run -itd --name moj-target debian /bin/bash Docker robi dwie rzeczy jednocześnie. Najpierw tworzy nowy kontener z obrazu (rezerwuje dla niego miejsce i pliki), a następnie go uruchamia. Parametr -d sprawia, że proces działa cicho w tle. Zgodnie z otrzymanym wynikiem, na ekranie zobaczysz tylko długi identyfikator. Kontener działa. Co dzieje się jednak, gdy go zatrzymasz poleceniem docker stop? Kontener przechodzi w stan uśpienia. On nadal istnieje na Twoim dysku i czeka na ponowne wywołanie. Jeśli teraz popełnisz klasyczny błąd nowicjusza i wpiszesz ponownie docker run, system wyrzuci błąd, że nazwa „moj-cel” jest już zajęta. Jeśli nie użyłeś flagi --name, Docker bezgłośnie stworzy nowy kontener z losową nazwą. W ten sposób po tygodniu obudzisz się z dwudziestoma kontenerami, które robią dokładnie to samo i bezczelnie zjadają Twoje zasoby. Jak temu zapobiec? Do uruchomienia już istniejącego, zatrzymanego kontenera służy wyłącznie komenda: docker start moj-cel Nic dodać, nic ująć. Pierwsze polecenie to stworzenie kontenera, drugie to po prostu uruchomienie. Uczmy się kontrolować nasze środowisko laboratoryjne. Porządek w terminalu to podstawa bezpiecznej pracy. Więcej o prawidłowym zarządzaniu cyklem życia kontenerów oraz konfiguracji flag -it opisałem w rozdziale 4 mojej książki „Laboratorium cyberbezpieczeństwa w Dockerze. Zrób to sam”. A jak to wygląda u Ciebie? Często łapiesz się na tym, że po wpisaniu docker ps -a widzisz na liście sporą liczbę zapomnianych, losowych kontenerów? Jak sobie radzisz z czyszczeniem środowiska? Daj znać w komentarzu. #Docker #Cybersecurity #SysAdmin #DevOps #ITSecurity

LinkedInKrzysztof Godzisz

docker run to operacja twórz i uruchom. Za każdym razem, gdy je wywołujesz, Docker tworzy nowy kontener z obrazu — niezależnie od tego, czy identyczny już istnieje na dysku. Jeśli użyłeś flagi --name, dostaniesz błąd kolizji nazw. Jeśli nie — Docker bezgłośnie powołuje kolejny kontener z losową nazwą i pożera zasoby.

docker start to operacja uruchom istniejący. Kontener zatrzymany przez docker stop nadal rezyduje na dysku w stanie uśpienia. To jego jedyna słuszna metoda powrotu do życia.

# Tworzy kontener — wywołuj tylko raz
docker run -itd --name moj-target debian /bin/bash

# Zatrzymuje bez usuwania
docker stop moj-target

# Przywraca do działania — to wołaj po każdym restarcie
docker start moj-target

W środowiskach testowych i CI/CD ten błąd jest szczególnie kosztowny. Zapomniane kontenery zajmują przestrzeń dyskową, mogą trzymać otwarte porty i powodować trudne do debugowania konflikty sieciowe. Jeden szybki audyt pozwala ocenić skalę problemu:

docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.CreatedAt}}"

Jeśli widzisz wiele kontenerów w stanie Exited z losowymi nazwami — masz dokładnie ten problem.

Czyszczenie środowiska sprowadza się do dwóch poleceń: docker container prune usuwa wszystkie zatrzymane kontenery, a docker system prune idzie dalej i czyści również nieużywane obrazy i wolumeny. Używaj drugiego z rozwagą w środowiskach współdzielonych.

Zasada jest prosta: docker run wywołujesz raz przy inicjalizacji, docker start — przy każdym kolejnym uruchomieniu. Jeśli zarządzasz wieloma środowiskami, rozważ przeniesienie definicji kontenerów do docker-compose.yml — docker compose up i docker compose down eliminują tę dwuznaczność całkowicie, bo stan środowiska jest deklaratywny i powtarzalny.

BNG z zewnętrzym DHCP

GitHub - 0return/BNG_DHCP_Relay: BNG with external DHCP - DHCP RELAY, NOS - TiMOS-B-25.7.R2 and bngblaster 0.9.18

BNG with external DHCP - DHCP RELAY, NOS - TiMOS-B-25.7.R2 and bngblaster 0.9.18 - 0return/BNG_DHCP_Relay

GitHub0return

Repozytorium zawiera konfiguracje i pliki związane z implementacją DHCP Relay w środowisku BNG (Broadband Network Gateway) z użyciem NOS TiMOS oraz narzędzia bngblaster. Znajdziesz tu m.in. pliki konfiguracyjne DHCP Server i DHCP Relay w formacie YAML, skrypty do testów wydajnościowych oraz schematy topologii i weryfikacji działania.

Automatyczne zarządzanie Cloudflare Tunnel

GitHub - ChrispyBacon-dev/DockFlare: DockFlare: Automate Cloudflare Tunnels with Docker Labels

DockFlare: Automate Cloudflare Tunnels with Docker Labels - ChrispyBacon-dev/DockFlare

GitHubChrispyBacon-dev

DockFlare to samoobsługowa platforma do zarządzania Cloudflare Tunnel, która automatycznie konfiguruje publiczny dostęp do kontenerów Docker bez ręcznej obsługi panelu Cloudflare. Dzięki integracji z metadanymi kontenerów i możliwością zarządzania regułami z poziomu interfejsu webowego, ułatwia szybkie i niezawodne wystawianie usług w sieci. 

Router ID w sieciach IPv6-native