Jak połączyć Vagrant z Jenkins, aby uzyskać idealne środowisko ciągłej integracji?

Masz projekt, który ma pewne wymagania dotyczące oprogramowania do uruchomienia (np. Konkretna wersja Apache, wersja PHP, instancja bazy danych MySQL i kilka innych programów).

Odkryłeś już Vagranta , więc Twoje środowisko wirtualne jest już skonfigurowane. Możesz tworzyć pudełka z plików konfiguracyjnych i książek kucharskich.

Zrozumiałeś również zalety systemu ciągłej integracji, takiego jak Jenkins .

Teraz chciałbyś połączyć te dwa światy (Vagrant i Jenkins), aby uzyskać idealne środowisko ciągłej integracji. Mówiąc dokładniej, nie chciałbyś instalować oprogramowania wymaganego przez projekt na maszynie z systemem Jenkins, ale chciałbyś użyć środowiska wirtualnego dostarczonego przez Vagrant do okresowego budowania projektu na jego szczycie. Oprogramowanie CI (Jenkins) zbuduje dla Ciebie Vagrant box, a następnie zbuduje i przetestuje Twój projekt.

Jak skonfigurowałbyś swoje środowisko, aby to osiągnąć?

continuous-integration jenkins vagrant

— Roberto Aloi
źródło

Ponadto Twoja konfiguracja Jenkins to Vagrant box, więc możesz uruchomić to środowisko CI na wielu platformach, ponieważ istnieje między nimi wiele różnic.

— Stephan Eggermont

Czy stworzyłeś takie środowisko? Połączenie Dockera i Jenkinsa jest już dobrze znane, jednak nie wystarczy dla środowisk Windows, w którym to przypadku jedyną dobrą opcją, IMO, jest Vagrant + Jenkins. Należy wziąć pod uwagę kilka aspektów, na przykład czy naprawdę potrzebujemy niewolników i w jakich kontekstach, czy też możemy użyć jednego serwera do stworzenia włóczęgiego środowiska budowania na projekt na żądanie (w wielu firmach tylko kilka projektów jest stale budowanych, większość rzadko jest budowana) czy też powinniśmy użyć tego razem z systemem deduplikacji, aby zmniejszyć zajmowany przez niego obszar.

— majkinetor

Odpowiedzi:

to dobre rozwiązanie dla systemu budowania, moja sugestia:

Twój obecny Jenkins działa jako główny CI (prawdopodobnie uruchomiony przez użytkownika jenkinsa)
Utwórz innego użytkownika na tej samej lub innej maszynie do pracy w trybie podrzędnym Jenkinsa
- jenkins slave może być wywoływany z jenkins master i może używać innego użytkownika, takiego jak vagrant, który miał pozwolenie i środowisko dla włóczęgi, dlatego nie będzie ingerował w oryginalny serwer główny jenkins
- stwórz swoje podstawowe pudełko włóczęgów, a następnie możesz je ponownie wykorzystać, aby przyspieszyć wdrożenie
Większość informacji instalacyjnych (pakietów) może być zarządzana przez puppet (lub szefa kuchni) w celu załadowania do twojego vm box.

Prawdopodobnie możesz rzucić okiem na veewee , który może tworzyć pudełko włóczęgów w locie.

Oto przewodnik Ułatw CI dzięki Jenkins CI i Vagrant dla moich wskazówek dotyczących tej sugestii.

— Larry Cai
źródło

Twój link jest niestety uszkodzony

— langlauf.io

Jeśli ktoś jest zainteresowany zepsutym linkiem, oto kopia Make CI łatwiejsza z Jenkins CI i Vagrant

— Gilberto Treviño

Możesz wypróbować wtyczkę Vagrant dla Jenkinsa, która obecnie obsługuje Jenkins CD 1.532.3

Możesz zobaczyć demo tej wtyczki działającej pod adresem http://unethicalblogger.com/2012/03/13/vagrant-plugin-in-action.html

— Christophe Furmaniak
źródło

ta wtyczka nie obsługuje Jenkinsa powyżej 1.490, więc to duże ograniczenie :-(

— kenyee

nie obsługuje też włóczęgów biegających na niewolnikach :(

— Christophe Furmaniak

Tak, ale wtedy musisz samodzielnie zająć się całym cyklem życia maszyny wirtualnej (utwórz, zniszcz lub nie na koniec pracy, ...). Ideą wtyczki jest to, że wtyczka robi to za Ciebie, a następnie możesz skupić się na swoim głównym celu: używać maszyny wirtualnej jako izolowanego kontenera.

— Christophe Furmaniak

Wspomniana wtyczka ma irytujące problemy, które nadal nie zostały rozwiązane ( Issues.jenkins-ci.org/browse/JENKINS-26326 ), a rozwój został zatrzymany rok temu. Nie poleciłbym.

— Ross Ivantsiv,

Uruchamianie instancji włóczęgi na żądanie w celu wykonania kompilacji brzmi jak właściwe. Jeśli ta wtyczka nadal nie działa?

— Atifm,

Osobiście sugerowałbym użycie Hashicorp Packera do zbudowania pudeł Vagrant dla programistów, a następnie użycie go do wygenerowania obrazu Dockera, AWS lub OpenStack, który można uruchomić w swoim systemie CI. Vagrant to niesamowite narzędzie, ale narzut maszyn wirtualnych może być trochę wysoki dla systemu CI, aby stale je zwiększać i zmniejszać, szczególnie jeśli chcesz naprawdę szybkiej informacji zwrotnej.

Na byłym kliencie po prostu raz uruchomiliśmy maszyny Vagrant z systemem, a następnie uruchomiliśmy kompilacje Dockera / virtualenv wewnątrz tych maszyn wirtualnych i okresowo je niszczyliśmy, gdy nastąpiła poważna aktualizacja lub problem z nieprawidłowym zachowaniem środowiska.

https://www.packer.io/docs/builders/openstack.html

— dragon788
źródło

Jeśli mogę zapytać, czy uruchomiłeś jenkins jako oddzielny użytkownik? Jeśli tak, to jak udało ci się zapewnić dostęp włóczęgom? Dzięki

— Jaswanth Manigundan

Tak długo, jak Vagrant jest zainstalowany normalnie, jest umieszczany na ścieżce systemowej. Same skrzynki są normalnie ładowane do katalogu domowego bieżącego użytkownika, ale możesz zastąpić katalog domowy włóczęgi zmienną środowiskową. Połączyliśmy wszystkie te elementy, a także sprawiliśmy, że pudełko było ściągane z określoną wersją w procesie kompilacji, tak aby była buforowana raz, a następnie ponownie używana.

— dragon788