Aktywne Wpisy
fsfdjf +14
szukam chłopa, oto co mogę od siebie zaoferować:
1. pełne uzębienie (nie licząc ósemek)
2. okazjonalne przebłyski moich chorób psychicznych
3. miękkiego psiura co kocha wszystkich to ciebie pewnie też pokocha
4. jedzenie jak będę miała ochotę akurat gotować
5. zamiłowanie do przemocy domowej
tylko poważne oferty
1. pełne uzębienie (nie licząc ósemek)
2. okazjonalne przebłyski moich chorób psychicznych
3. miękkiego psiura co kocha wszystkich to ciebie pewnie też pokocha
4. jedzenie jak będę miała ochotę akurat gotować
5. zamiłowanie do przemocy domowej
tylko poważne oferty
Mam taki problem/rokminkę. Nie wiem czy w ogóle da się to zrealizować, ale może ktoś będzie mieć jakiś pomysł.
Mam zdefiniowany service w systemd. W ramach startu uruchamiany jest proces (np docker-compose), a on z kolei wykonuje inny proces potomny (czyli docker). Po wystarowaniu i sprawdzenia jego statusu, otrzymujemy info "active running".
Teraz wykonujemy docker-compose stop i start, proces kontenera jest zabijany i nowy umieszczany w innym namespace, czyli otrzymuje nowy pid, w związku z czym systemd zdefiniowanego service'u przechodzi w status "inactive dead". Co jest oczywiście zrozumiałe.
Czy istnieje jakiś sposób, jakiś check, cokolwiek aby service wykrył nowy proces uruchomiony z palca? W sensie, żeby wiedział, ze jest nowy proces i jego status wrócił do wartości "active running"? Nie wiem jak podłączyć takiego checka do service'u. Bo z wykryciem nowego procesu nie ma problemu (zwykły grep na procesy), ale jak zmusić systemd do dynamicznej zmiany?
Najprościej byłoby zdefiniować regułę dla systemctl status, usluga ale systemd nie umożliwia takiej funkcjonalności ;/
@tyu38: Ale czemu robisz to z palca zamiast ten start i stop zrobić przez systemctl?
Druga rzecz to jak chcesz mieć kontenery zintegrowane z systemd to w mojej opinii lepiej jakbyś skorzystał z podmana. Podman to backend zastępujący dockera który działa w innej architekturze - zamiast daemona klient-serwer masz kontenery dockerowe uruchamiane i
Komentarz usunięty przez autora
Bo chce podłączyć dashboard pod kontenery. Jak przez niego wykonam start/stop/restart to właśnie ta wyżej wymieniona sytuacja będzie mieć miejsce.
A muszę mieć status service'a prawidłowy, bo cały monitoring kleknie.
@Kryspin013
Ogólnie się zgadzam z tym podmanem. Dodałbym wśród zalet jeszcze bezpieczeństwo, bo niema jednego procesu matki uruchomionego na roocie.
Ale w moim przypadku podmam odpada. Brak właśnie tych uprawnień docker-engine na roocie, nie pozwala mi wszystkiego zrobić, do tego podman
@tyu38: tzn?
@tyu38 o czym konkretnie piszesz? Zazwyczaj to czego domyślnie podman nie dostarczał okazywało się że już istnieje w jakiejś formie w necie np podman-compose.
Np docker-engine na rocie pozwala łączyć sieci kontenera z sieciami hosta, dzięki czemu na fwlu możesz bardzo transparentnie zarządzać.
W podmanie nie ma np "--iptables=false", a potrzebuję to, bo sam buduję sieć od zera dla kontenerów.
Ogólnie rzecz ujmując bardzo mocno zmodyfikowałem konfiguracje i architekturę kontenerów, dlatego potrzebuję wiele różnych dziwnych opcji, o których mało kto wie.
Ale odchodzimy od tematu, bardziej tu chodzi o systemd niż o konteneryzację.
Na podmanie na pewno masz opcje zarządzania sieciami jak w dockerze bo kubernetes z tego korzysta i jest kilka scenariuszy na ogarnięcie sieci przy instalacji. A nie twierdzę, że podman jest rozwiązaniem twojego problemu.
Natomiast to co próbujesz zrobić to kompletne zepsucie założeń systemd i nie wiem
Dlatego napisałem na początku, że nie wiem czy to da się zrobić:D
Tu akurat architektura nie ma żadnego znaczenia. Chodzi właśnie o filozofię systemd, czy jest w stanie dynamicznie zmieniać pilnowane procesy....
Kubernetes buduję sieci zgodnie z założeniem konteneryzacji. Pody przykrywane są natami nodów w komunikacji z Światem. Teraz sobie wyobraź sytuację, że nie używasz żadnych natów i całą sieć na najniższej warstwie budujesz sam :) A po to mi docker-engine