Bardziej znane systemy zarządzania konfiguracją (CM), takie jak Puppet i Chef, wykorzystują podejście oparte na ciągnięciu: klienci okresowo odpytują scentralizowanego mastera w celu uzyskania aktualizacji. Niektóre z nich oferują masterless podejścia, jak również (tak, push-based), ale stwierdza, że jest to „nie do produkcji” (Saltstack) lub „mniej skalowalne” (Lalek). Jedyny znany mi system oparty na push od samego początku to drugie miejsce Ansible.
Jaka jest szczególna zaleta skalowalności systemu opartego na ściąganiu? Dlaczego podobno łatwiej jest dodawać więcej suwaków niż agentów push?
Na przykład agiletesting.blogspot.nl pisze:
w systemie „pull” klienci kontaktują się z serwerem niezależnie od siebie, więc system jako całość jest bardziej skalowalny niż system „push”
Z drugiej strony Rackspace pokazuje, że mogą obsługiwać systemy 15K za pomocą modelu push.
infastructures.org pisze:
Przysięgamy, że zastosujemy metodologię ściągania dla utrzymania infrastruktury, przy użyciu narzędzia takiego jak SUP, CVSup, serwer rsync lub cfengine. Zamiast wypychać zmiany do klientów, każda indywidualna maszyna kliencka musi być odpowiedzialna za odpytywanie złotego serwera podczas rozruchu, a następnie okresowo, aby utrzymać swój własny poziom obrotów. Przed przyjęciem tego punktu widzenia opracowaliśmy obszerne skrypty push oparte na ssh, rsh, rcp i rdist. Problem, który znaleźliśmy w przypadku komend r (lub ssh) był następujący: po uruchomieniu skryptu opartego na komendach r w celu wypchnięcia zmiany na maszyny docelowe, istnieje prawdopodobieństwo, że jeśli masz więcej niż 30 hostów docelowych, jeden z nich będzie być w dowolnej chwili. Utrzymanie listy uruchomionych maszyn staje się koszmarem. W trakcie pisania kodu, aby to naprawić, skończysz z rozbudowanym kodem opakowania, aby poradzić sobie z: limity czasu od martwych gospodarzy; rejestrowanie i ponawianie prób martwych hostów; rozwidlanie i uruchamianie równoległych zadań, aby spróbować trafić do wielu hostów w rozsądnym czasie; i wreszcie wykrywanie i zapobieganie przypadkowi wykorzystania wszystkich dostępnych gniazd TCP na maszynie źródłowej we wszystkich wychodzących sesjach rsh. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które zginą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. rozwidlanie i uruchamianie równoległych zadań, aby spróbować trafić do wielu hostów w rozsądnym czasie; i wreszcie wykrywanie i zapobieganie przypadkowi wykorzystania wszystkich dostępnych gniazd TCP na maszynie źródłowej we wszystkich wychodzących sesjach rsh. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które umrą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. rozwidlanie i uruchamianie równoległych zadań, aby spróbować trafić do wielu hostów w rozsądnym czasie; i wreszcie wykrywanie i zapobieganie przypadkowi wykorzystania wszystkich dostępnych gniazd TCP na maszynie źródłowej we wszystkich wychodzących sesjach rsh. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które zginą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. i wreszcie wykrywanie i zapobieganie przypadkowi wykorzystania wszystkich dostępnych gniazd TCP na maszynie źródłowej we wszystkich wychodzących sesjach rsh. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które zginą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. i wreszcie wykrywanie i zapobieganie przypadkowi wykorzystania wszystkich dostępnych gniazd TCP na maszynie źródłowej we wszystkich wychodzących sesjach rsh. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które umrą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które zginą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. W dalszym ciągu masz problem z umieszczeniem wszystkiego, co właśnie zrobiłeś, w obrazach instalacyjnych dla wszystkich nowych hostów do zainstalowania w przyszłości, a także z powtórzeniem tego dla wszystkich hostów, które zginą i będą musiały zostać odbudowane jutro. Po kłopotach, jakie przeszliśmy, aby wdrożyć replikację opartą na poleceniach r, okazało się, że nie jest tego warte. Nie planujemy ponownie zarządzać infrastrukturą za pomocą komend r ani za pomocą żadnego innego mechanizmu wypychania w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. lub z dowolnym innym mechanizmem pchającym w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu. lub z dowolnym innym mechanizmem pchającym w tym zakresie. Nie skalują się tak dobrze, jak metody oparte na ściąganiu.
Czy nie jest to problem implementacyjny zamiast architektonicznego? Dlaczego trudniej jest napisać wątkowego klienta push niż wątkowy serwer pull?
ansible-pull.