Gdzie w Proxmoksie umieścić Dockera: decyzja o miejscu i pułapka compose

Proxmox jest zainstalowany i chcesz uruchamiać kontenery. Pytanie nie brzmi, jak to zainstalować, tylko gdzie to postawić. A to nie jest kwestia gustu, tylko kwestia tego, ile rzeczy się psuje, gdy zepsuje się jedna.

Trzy miejsca

Bezpośrednio na hoście. Najłatwiejsze i dokładnie to, którego nie należy wybierać. Host jest warstwą, na której opiera się wszystko powyżej. Cokolwiek tam zainstalujesz, znajduje się od tej chwili w promieniu rażenia każdej maszyny wirtualnej: konflikt zależności, zapełniony dysk albo zła aktualizacja zabierają nie tylko twoje kontenery, ale wszystko naraz.

Wewnątrz kontenera systemowego. Lekkie i szybkie w postawieniu. W zamian uruchamiasz kontenery wewnątrz kontenera, a ten układ ma swoje ostre krawędzie: model uprawnień, warstwy systemu plików, współdzielone jądro. Wybrany świadomie jest rozsądny; wybrany dlatego, że tak było łatwiej, produkuje niespodzianki.

Wewnątrz maszyny wirtualnej. Na papierze najcięższe, w praktyce najczystsze. Gdy układ kontenerów się przewróci, przewraca się jedna maszyna wirtualna, a nie twój serwer. A gdy chcesz go odbudować, odbudowujesz jedną maszynę.

Jedno pytanie, które rozstrzyga

Jeśli to się zepsuje, co stanie się z całą resztą? Na hoście odpowiedź brzmi wszystko, wewnątrz maszyny wirtualnej odpowiedź brzmi jedna z nich. Zużycie zasobów, łatwość instalacji, to wszystko jest drugorzędne wobec tej odpowiedzi.

Druga połowa: compose jest programem

Plik compose wygląda na konfigurację. Nie jest. Uruchomienie go jest uruchomieniem kodu, a ten kod działa z twoimi uprawnieniami. Dwie linie w środku potrafią oddać kontenerowi całą maszynę.

Gdy ludzie kopiują plik compose z internetu, nie czują niepokoju, który czują przy kopiowaniu polecenia. Różnica nie leży w niebezpieczeństwie, tylko w wyglądzie: polecenie wygląda jak polecenie, a compose wygląda jak plik ustawień. Wyglądanie na plik ustawień nie czyni go bezpiecznym.

Cztery linie, na które warto spojrzeć przed uruchomieniem

Czy montuje wewnątrz system plików hosta. Czy prosi o tryb uprzywilejowany. Czy podaje kontenerowi do środka gniazdo samego zarządzania. Czy używa bezpośrednio sieci hosta.

Te cztery to linie przebijające granicę kontenera: jeśli któraś z nich tam jest, ten kontener nie jest już kontenerem, tylko samym hostem. Przeczytanie ich zajmuje dziesięć sekund, a te dziesięć sekund jest warte więcej niż cała reszta tego wpisu.

Co robi Atlas

Atlas skanuje pliki compose i skrypty instalacyjne przed instalacją, a ten skan siedzi na serwerze, nie w interfejsie. Cokolwiek więc wyśle interfejs, sprawdzenia nie da się pominąć.

Wyniki przychodzą na dwóch poziomach. Czerwony oznacza coś, co wyprowadza kontener poza granicę kontenera, czyli uprawnienie równoważne hostowi; wtedy wymagana jest wyraźna zgoda. Żółty oznacza coś, co można zrobić świadomie, ale o czym trzeba ci powiedzieć. Po stronie katalogu aplikacji czerwony nie jest przyjmowany w ogóle.

Jest jeszcze jeden szczegół i on ma znaczenie: skaner nie wygłasza opinii, tylko podaje fakty. Nie mówi, że to jest niebezpieczne, mówi, że ta linia robi to a to. Decyduje czytający, bo ta sama linia bywa dopuszczalna w jednym układzie i niedopuszczalna w innym.