Cześć, jest jakaś w praktyce różnica między instalowaniem wszystkich usług w kontenerach dockera lub lxc i wystawianiem odpowiednich portów z kontenerów na świat a instalowaniem bezpośrednio na hoście jeśli chodzi o bezpieczeństwo, utrzymanie takiego systemu, zapewnienie bezawaryjnej pracy? Pytam bo widzę że wiele rzeczy, które używam jest dostępne jako obrazy dockera i można nawet przez docker-compose je postawić. Lepiej instalować usługi w dockerach lub kontenerach lxc czy bezpośrednio na serwerku?
0
1
Różnica jest ogromna na korzyść konteneryzacji. Co prawda znam i używam tylko dockera, ale izolacja zależności, ograniczenie zasobów cpu/ram, jasno określone "interfejsy" (czyli: porty, wolumeny, środowisko), backupy, bardzo proste upgrade i utrzymanie, logi, telemetria, Dockerhub gdzie praktycznie niemożliwe jest żeby czegoś nie było już gotowego do użycia. O k8s nawet nie wspominam, bo to już zupełna bajka :)
0
Czyli używałbyś kontenerów na serwerze zamiast bezpośrednio na nim instalować usługi?
1
Praktycznie zawsze. Pytanie też, co masz na myśli mówiąc "usługa". Jeśli to jest usługa systemowa, typu cron, no to wiadomo nie, nie przesadzajmy :) Ale wszystkie aplikacje pisane przez deweloperów tylko zyskują, tak samo bazy danych (#unpopularopinion), jakieś toole typu pgAdmin czy Grafana, instalowanie tego natywnie jest bez sensu. Wiadomo są wyjątki, typu gdy wymagana jest super wydajność albo natywny dostęp do dysku itp.
0
A jak jest z bezpieczeństwem kontenerów versus natywnie na hoście, zakładając że używam zabezpieczeń takich jak selinux?
1
Powiem tak - spróbuj obie opcje. Zainstaluj sobie na jakimś serwerze trochę rzeczy - jakiś standardowy devopsowy stos typu ELK, Prometheus+Grafana, jakieś kilka narzędzi deweloperskich typu pgAdmin. I zobacz jak się z tym pracuje natywnie (typu instalacja z repo APT) i z Dockerem. Zobacz jak się backupuje, gdzie aplikację się konfiguruje, jak podbić wersję (to jest akurat największy bajer konteneryzacji). Sam zobaczysz :)
0
Ok, a jak to się ma do stabilności? Bo w sumie to przy standardowym podejściu masz system oraz stojące na nim usługi. Jak padnie hardware lub system to całość leży i kwiczy. Jak padnie jedna usługa to reszta sobie działa.
A przy kontenerach to po pierwsze mamy dodatkowe ogniwo, które może spowodować problemy (błędną konfiguracja, jakiś bug, kwestia kompatybilnosci itp.) a do tego jak padnie docker to pewnie zdechnie wszystko, co na nim jest postawione (a nie jakaś jedna konkretną usluga).
1
Co do bezpieczeństwa - są narzędzia do testowania obrazów pod tym kątem. Np Trivy.
3
przykład może mało prawdopodobny ale proponuję na serwerze zainstalować obok siebie php 3,4,5,6,7,8,9.
Oj było by to wyzwanie, a podejrzewam że doker by to ogarnął szybko.
Starsze wersje programów mogą być dość problematyczne w uruchomieniu bo pakietów brak a samemo skompilować też może nie być łatwo bo inne wersje bibliotek itp.
Jak się człowiek uprze to zawsze się da ale trochę czasu szkoda
Jeżeli patrzymy na projekt IT nie w perspektywie "dzisiaj" tylko np. za 10 lat to ja widzę same zalety dokera związane z długoterminowym utrzymaniem projektu przy życiu
1
Abstrahując już od bezpieczeństwa i stabilności, które również się poprawiają to dla samego porządku w systemie i braku problemów z różnymi wersjami bibliotek opłaca się używać dockera. Jak raz zaczniesz to już nigdy nie wrócisz do normalnego instalowania aplikacji.
3
Ja mam inne podejście do dockera i pewnie skoro jest tu większość developerów to mnie zjadą :), ale jako administrator wolę postawić sobie usługę systemową, tym bardziej jeśli mowa o webserwerze o cronach nie wspominając. Docker wszędzie jako zastępstwo wszystkich usług systemowych zje zasoby i nie jest stabilny, chyba że go kalstrujemy i używamy ewentualnie docker swarma. Docker również w takim podejściu nie ma nic wspólnego z bezpieczeństwem.
Debugowanie jakichś faili czy logów - docker vs usługi systemowe też na korzyść tego drugiego pod każdym względem.
Jest to dobre środowisko uruchomieniowe, ale w połączeniu z kluczowymi usługami systemowymi tylko do wystartowania i obsługi danej aplikacji, gdzie mogę szybko cofnąć zmiany po nieudanym deployu.
LXC i docker to też również dwie różne rzeczy, z dockera ucieknę w bardzo prosty sposób jak się dostanę do wnętrza niezabezpieczonej apki, z LXC już jest trudniej.
Kubernetesa bym tutaj nie łączył w tym temacie bo to jeszcze inna warstwa, gdzie da się już zabezpieczyć środowisko i uodpornić na faile.
3
Docker to przede wszystkim sposób pakowania i uruchamiana aplikacji.
Bezpieczeństwo dockera to dla mnie raczej dodatek, niż główna funkcjonalność. Opiera się na możliwościach samego jądra Linuksa, jak chroot, namespqces (np. oddzielne sieci wirtualne dla grupy kontenerów dzięki networking namespace), capabilities (https://man7.org/linux/man-pages/man7/capabilities.7.html) i kilka innych. Więc teoretycznie można to wszystko osiągnąć samym Linuksem, tylko trzeba wiedzieć co się robi.
Dodatkowo są narzędzi do skanowania obrazów dockera pod kątem bezpieczeństwa, jak trivy, snyk lub inne zintegrowane z samym rejestrem (quay, gitlab w wersji ultimatum, etc).
Sam docker jednak nie zapewnia orkiestracji usług. Uruchomienie usług na serwerze bezpośrednio przez dockera to nieporozumienie. Moja poprzednia firma pakowała docker-compose w jednostki systemd aby to obejść. Czy to ma sens? Może, nie wiem. Ja zdecydowanie wolę korzystanie z k8s.
2
trochę pisałem o tym tutaj