Tag Archives: openshift

Openshift pt3 Testuj w chmurze z Jenkins CI

build

W poprzednim tutorialu umieściłem apke na Jenkins’ie  aby mogła się automatycznie budować po zmianach w repo
http://przemek.yum.pl/openshift-2-buduj-w-chmurze-z-jenkins-ci/

Teraz czas na zabawę z setup’em Jenkins’a

  1. Zacznę od pluginów – zainstalujemy je klikając na Manage Jenkins  -> Manage Plugins  i już tutaj czeka na nas pierwsza pułapka
    W sekcji Available jest no właśnie – nic  – przechodzę do zakładki Advanced
    i tu klikam na  Check Updates. ten proces może potrwać dość długo – nawet kilka minut znane też były problemy z Chrome więc warto uzbroić się w cierpliwość.
    W najgorszym przypadku pluginy można dodać  z kompa.
  2. Dodaj plugina – oto opisy poszczególnych, które zainstaluje
    https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin
    https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin
    https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View
    https://wiki.jenkins-ci.org/display/JENKINS/Extra+Columns+Plugin
     i najważniejsze
    https://wiki.jenkins-ci.org/display/JENKINS/Green+Balls
  3. Będziemy jeszcze potrzebować wtyczki którą trzeba zainstalować ręcznie
    JBehave plugin  do pobrania tu https://nexus.codehaus.org/content/repositories/releases/org/jbehave/jbehave-jenkins-plugin/ i wybieram najnowszą oficjalną wersję, potem należy wybrać plik z rozszerzeniem hpi i mamy wtyczkę 🙂
    Gdyby jednak i pozostałe trzeba było ściągnąć – oto linki do nich
    http://updates.jenkins-ci.org/download/plugins/xunit/
    http://updates.jenkins-ci.org/download/plugins/greenballs/
    http://updates.jenkins-ci.org/download/plugins/cobertura/
    http://updates.jenkins-ci.org/download/plugins/dashboard-view/
    wystarczy klik w permalink i mamy pluginki
  4. Instalujemy je (zakładka Advaced) z kompa lub przez zakładke Available
    Po instalacji trzeba zrobić restart Jenkinsa – wbijam pod adres:
    https://jenkins-chmura.rhcloud.com/restart no i zatwierdam
  5. Naszym oczom ukazuje się greenball – koniec z dziadowskim niebieskim po udanym buildzie 🙂 Aale wato dodać więcej customu – klikam znak +  nad job’em i dodaje Dashboard. Wchodzę na niego i wybieram opcje po prawej stroni Edit View. Teraz można eksperymentować z jakimiś ciekawymi layoutami

Koniec zabawy  czas na konfiguracje job’a –
https://jenkins-chmura.rhcloud.com/job/calculator-build/configure

  1. Max # of builds to keep – jak już wspomniałem tak max 10
  2. Execute shell to jest ważne pole – znajduje się tu skrypt budowania apki
    Co jest ważne – gear build  trigger’uje

    mvn -e clean package -Popenshift -DskipTests'

    dlatego trzeba dodać fazę testów do naszego build’a – jest nawet na to przygotowane miejsce pod komentarzem 

    # Run tests here

    Więc dopisuję odpalanie testów i drobne info na konsole

    echo Starting tests
    mvn test

    Jeśli chodzi o nadpisanie zmiennej openshift’owej gear build  to niestety nie znalazłem rozwiązania i trzeba się z tym męczyć dodając osobno budowanie testów
    Dalej są dobrze udokumentowane stepy kopiowania zasobów pomiędzy pre i produkcyjnym środowiskiem oraz informacje o repo itd.

  3. Natepnie dodaję Post-build Action : Publish Cobertura Coverage Report
    ustawiam  pattern na: **/coverage.xml
    Wtyczka prezentuje raport porycia kodu przez testy
  4. Dodaję znów Post-build Action: Publish xUnit test result report
    Pod przyciskiem Add wybieram JBehave-3.x i ustawiam pattern an:
    **/jbehave/*.xml
    Aplikacja testowa którą sugeruje pobrać posiada testy BDD – jeśli w teojej aplikacji takich testów nie ma, można pominąć ten krok – ale zapraszam do tutorialu poświęconego dodawaniu testów BDD do projektu (TODO)
  5. Z pewnych ciekawych powodów wtyczka JBehave nie pozwala na odznaczenie opcji Post-build Action: Publish JUnit test result report z pattern’em **/*Test.xml. (Bo tak nazywam moje unit testy). Zaobserwowałem jednak pewną niestabilność i trzeba czasem pokombinować z dodaniem – usunięciem którejś ze wtyczek – widać kolejność ma znaczenie 🙂 Finalnie dane z testów powinny pochodzić z JBehave i z JUnit a przy padniętym buildzie po stronie unit testów tylko z JUnit. A co się stanie przy padniętych testach JBehave – trzeba sprawdzić 😀

Zapisuję tę ciężką pracę i odpalam build’a – zobaczmy co powie 😀

Już po dwóch build’ach powinien nam się ukazać taki oto widok:

build_coverage2

Czas coś w końcu dodać od siebie i zobaczyć jak maszina działa 😛

Wbrew boskim przykazaniom TDD zkodziłem sobie nową metodkę szybko i bezmyślnie

\src\main\java\com\rhcloud\pbtest\calculator\Calculator.java
  public void divide(int number1, int number2) {
        result = number1+number2;
    }

Co na to CI? Pokrycie kodziku spadło – w folderku Workscpace -> target/site/cobertura/index.html po kliknięciu w klasę znalazłem winnego

cobertura error

Dodaję więc klaskę testową już trochę bardziej przytomnie i push’uje na repo :

public class CalculatorDivideTest {
    private Calculator calc = new Calculator();

    @Test
    public  void shouldDivideNumberByAnotherNumber(){
        calc.divide(4,2);
        assertEquals("Divide unsuccessfull", 2, calc.getResult());
    }

}

Ola Boga cożech się stało – no tak… (smutek) Build czerwony…

No to szybko do wyników pod linkiem Test Result  a tam jak nic jest Test wywalony

calculator.CalculatorDivideTest.shouldDivideNumberByAnotherNumber

Error Message Divide unsuccessfull expected:<2> but was:<6>
Stacktrace 
java.lang.AssertionError: Divide unsuccessfull expected:<2> but was:<6>

Fiksuje ten niewybredny błąd w mojej metodzie i wszystko wraca do zieloności 🙂

Warto wiedzieć
  1. Logi na Jenkis można podglądnąć:
    a) Wchodząc w job’a i klikając na ikonkę Ball w Build History
    b) Wchodząc w konkretnego build’a w Build History  -> Console Output
    c) Dodając i konfigurując Extra Collumn plugin – najświeższe logi są dostępne już z job’a – efekt możecie podziwiać na obrazku na początku postu 🙂
  2. W Manage Jenkins -> Cnfigure System->Default view możemy ustawić naszeg custom’owego dashbord’a 🙂
  3. Nie trzeba wpadać na Jenkins’a aby szybko podglądnąc jaki był wynik build’a – w terminalu wystarczy wpisać i dostaniemy feedback – to jest generyczne dla każdej openshift’owej apki – czyli można też tak podglądnąć logi apki calculator
    rhc tail jenkins
    Nov 03, 2013 3:12:44 AM hudson.model.Run execute
    INFO: calculator-build #59 main build action completed: SUCCESS
  4. Pliki po zbudowaniu apki w job’ie na testowym workspace są automatycznie kasowane po 15 minutach bezczynności – jednak można to obejść
    po pierwsze wydłużając ten czas w ustawieniach Jenkinsa do 60min w Slave Idle Time to LiveMax Slave Idle Time to Live
    po drugie dodając nowego jenkins’owego job’a  (ustawienia konfiguracyjne trzeba skopiować z głównego job’a [bez git’a, shell’a i plugin’ów ]) i ustawiając cron’a w Build Triggers  na np  0,55 * * * *   czyli co 55min będzie wykonywał się pusty build więc pliczki nie powinny być kasowane

To by było na tyle odnośnie testów, Jenkins na Openshift. Z pewnością w innych postach będę wspominał o różnych sposobach testowania apki javowej – co z powodzeniem można zastosować w chmurze 🙂 ….

W kolejnym poście opiszę proces dodania bazki i phpMyAdmin do apki na Openshift link (TODO)

 

 

Openshift pt2 Buduj w chmurze z Jenkins CI

Czas na część drugą

Warto znać, warto mieć:
Git + np: GitHub – poziom podstawowy
Projekt: java + maven – w poście jest link do testowegej apki więc nawet bez projektu się da 🙂

Mamy projekcik i  warto by było go wrzucić  na Openshift.  To zostało opisane w poprzednim poście http://przemek.yum.pl/openshift-pt1-stawianie-javowej-apki-w-chmurze/ więc cóż więcej można na tej chmurze robić?

Ciągła Integracja jest na to odpowiedzią. Można to opisać w kilku prostych krokach. Zakładam jakąś podstawową znajomość systemu kontroli wersji GIT:

  1. Posiadam kod na zewnętrznym repo np: GitHub
  2. Gdy coś zmienię w kodzie i robię commit a następnie push zewnętrzne repo zostaje zaktualizowane
  3. Na Openshift postawiony jest sprytny tool Jenkins – narzędzie do ciągłej integrajcji które nasłuchuje zmiany na repo zewnętrznym
  4. Gdy takie się pojawią Jenkins buduje zaktualizowany kod, wykonuje testy i jeszcze inne cuda co sobie zażyczymy stawiając testową aplikacje
  5. I jeśli wg zdefiniowanych kryteriów build się powiódł Jenkins robi deploy na instancję np. testową/pre-produkcyjną.
  6. Dzięki temu procesowi działająca apka z nowymi feature’ami jest dostępna od razu po wprowadzeniu i push’nięciu zmian (o ile testy się nie sypły 🙂 ). 

Brzmi nieźle  – But how???

  1. Tworzymy testową apkę na openshift
    $ rhc app create calculator jbossas-7

    Przykładowy wynik

    Application Options
    -------------------
      Namespace:  chmura
      Cartridges: jbossas-7
      Gear Size:  default
      Scaling:    no
    
    Creating application 'calculator' ... done
    
    Waiting for your DNS name to be available ... done
    
    Downloading the application Git repository ...
    Cloning into 'calculator'...
    The authenticity of host 'calculator-chmura.rhcloud.com (107.20.34.166)' can't be established.
    RSA key fingerprint is aa:aa:aa:aa:aa:aa:aa.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'calculator-chmura.rhcloud.com,107.20.34.166' (RSA) to the list of known hosts.
    remote: Counting objects: 32, done.
    remote: Compressing objects: 100% (23/23), done.
    remote: Total 32 (delta 0), reused 32 (delta 0)
    Receiving objects: 100% (32/32), 16.27 KiB, done.
    
    Your application code is now in 'calculator'
    
    calculator @ http://calculator-chmura.rhcloud.com/ (uuid: 000000000000000000)
    -----------------------------------------------------------------------------------
      Created: 8:48 PM
      Gears:   1 (defaults to small)
      Git URL: ssh://0000000000000@calculator-chmura.rhcloud.com/~/git/calculator.git/
      SSH:     00000000000000@calculator-chmura.rhcloud.com
    
      jbossas-7 (JBoss Application Server 7)
      --------------------------------------
        Gears: 1 small
    
    RESULT:
    Application calculator was created.
    Artifacts deployed: ./ROOT.war

    mam loklane repo z aplikacją na openshift Yupii 😀

  2. To repo przyda się jak będziemy chcieli coś wrzucić bezpośrednio do naszej aplikacji ale mamy chrapkę na CI więc na razie możemy je zignorować  i w każdym innym miejscu na naszym kompie rozpocząć developowanie apki gdyż tak naprawdę Jenkins będzie nasłuchiwał zewnętrznego repozytorium z GitHub (zob. obrazek na końcu postu).
  3. Dlaczego? Bo raczej nieeleganckie będzie utrzymywanie głównego repo na Openshift – ze względu na jego marne możliwości jeśli chodzi o funkcje które dostaniemy na GitHub czy BitBucket jeśli chodzi o np Code Review, czy dzielenie się dostępem do kodziku. 
  4. Jeśli nie masz gotowego projektu maven’owego możesz zrobić Fork’a z repozytorium GitHub –  projektu https://github.com/AdupTeam/Jbehave oraz stworzyć lokalne repo fork’owanego projektu na kompie. Jeśli posiadasz projekt dodaj do niego folder z .openshift, z folderu repo aplikacji Openshift z punktu 2 (folderek jest wymagany podczas transferu plików  pomiędzy aplikacją testową a finalną) oraz dodać profil do pom.xml (patrz poprzedni post)
  5. Dalej w tej samej lokacji tworzę instancję Jenkins’a
    $ rhc app create jenkins jenkins-1

    Przykładowy wynik

    Application Options
    -------------------
      Namespace:  chmura
      Cartridges: jenkins-1
      Gear Size:  default
      Scaling:    no
    
    Creating application 'jenkins' ... done
    
    Waiting for your DNS name to be available ... done
    
    Downloading the application Git repository ...
    Cloning into 'jenkins'...
    remote: Counting objects: 8, done.
    remote: Compressing objects: 100% (5/5), done.
    rRemote: Total 8 (delta 0), reused 8 (delta 0)
    Receiving objects: 100% (8/8), 722 bytes, done.
    
    Your application code is now in 'jenkins'
    
    jenkins @ http://jenkins-chmura.rhcloud.com/ (uuid: 00000000000000000000000000)
    -----------------------------------------------------------------------------
      Created: 10:59 PM
      Gears:   1 (defaults to small)
      Git URL: ssh://00000000000000000000@jenkins-chmura.rhcloud.com/~/git/jenkins.git/
      SSH:     000000000000000000000@jenkins-chmura.rhcloud.com
    
      jenkins-1 (Jenkins Server)
      --------------------------
        Gears: 1 small
    
    RESULT:
    Application jenkins was created.
    
    Jenkins created successfully.  Please make note of these credentials:
    
       User: admin
       Password: 00000000000
    
    Note:  You can change your password at: https://jenkins-chmura.rhcloud.com/me/configure

    W ostatnich linijkach mam link do działającego Jenkins’a oraz passy aby się zalogować.

  6. Teraz czas powiązać aplikacje Openshift z Jenkins’em – w punkcie 1 stworzyłem appke calculator i to jej użyjemy. No i tu zaczyna się trochę tricky part. Normalnie Jenkins buduje lokalnie aplikacje i deploy’uje pod wskazane miejsce – na Openshift jest inaczej – Jenkins potrzebuje tzn workspace do budowania apki – dlatego potrzebne jest stworzenie instancji aplikacji specjalnie dla Jenkins’a. Ta przestrzeń będzie wykorzystana do próbnego build’a.
    $ rhc cartridge add jenkins-client -a calculator

    Przykładowy wynik

    Using jenkins-client-1 (Jenkins Client) for 'jenkins-client'
    Adding jenkins-client-1 to application 'calculator' ... Success
    
    jenkins-client-1 (Jenkins Client)
    ---------------------------------
      Gears:   Located with jbossas-7
      Job URL: https://jenkins-chmura.rhcloud.com/job/calculator-build/
    
    RESULT:
    Added jenkins-client-1 to application calculator
    
    Associated with job 'calculator-build' in Jenkins server.
  7. Loguję się do Jenkins’a. Job automatycznie został skonfigurowany i dodany jako calculator-build. Można go spokojnie odpalić za pomocą opcji Schedule Build (zegarek po prawej) no i zbuduje się default’owa apka – ale potrzeba naszego kodu. Wchodzę do joba u mnie https://jenkins-chmura.rhcloud.com/job/calculator-build/ i klikam Configure po lewej stronie.  
  8. Od razu zmieniam Max # of builds to keep na 5 aby nie zapychać pamięci skromnej maszynki, ale gwoździem programu jest zmiana repo – zmieniam link z repozytorium z Openshift na to z GitHub (kontrolka  HTTPS clone URL na GitHub’ie) i zachowuję zmiany.
    Dodatkowo zaznaczam w  Build Triggers opcje Poll SCM i w polu Shedule dodaje * * * * *  co oznacza, że CI będzie co minutę sprawdzał czy nie zaszły zmiany na GitHub repo. Więcej o tej funkcji i tajemniczych gwiazdkach można poczytać w klikając pytajnik obok okna w które wpisaliście gwiazdki albo wyszukując w necie informacje na temat cron np tu http://www.wiki.mydevil.net/Cron
  9. Zapisuję i wystarczy teraz odpalić builda i TADAAA
    https://calculator-chmura.rhcloud.com/
    aplikacja została zbudowana z naszego repo na GitHub
  10. Za każdym razem kiedy coś push’niemy Jenkins automatycznie wykona akcję Run Build na CI, który zbuduje (o ile jest zbudowywalna 😀 ) naszą apke 🙂 A oto ścieżka jaką przemierza nasz kodzikJenkinsGit
  11. A co się stanie jak apka się nie zbuduje – NIC i to jest cała magia – brzydki kodzik nie trafi na produkcję a użytkownicy naszego kalkulatora dalej będą się cieszyć działającym softem 😀

Warto wiedzieć

  1. Czas naszej maszynki niestety będzie się różnić od czasu lokalnego więc należy przygotować sie na to, że jakiś stały zamorski interwał będzie dzielić nasze strefy
  2. Openshift usypia nieużywane maszynki – więc taka maszynka potrzebuje chwilę aby wstać

W kolejnej części bardziej szczegółowo omówię konfiguracje Jenkins’a. Będą ciekawe przykłady  pracy Jenkins’a w kontekście testowania aplikacji… http://przemek.yum.pl/openshift-pt3-testy-w-chmurze-na-jenkins-ci/

Openshift pt1 Stawianie javowej apki w chmurze

Wiele rzeczy da się zrobić przez openshift’owego klienta webowego jednak gdzie jest w tym fun 🙂
Aby  cieszyć się apką na Openshift należy posiadać zainstalowanego Git, dodatkowo warto zauważyć, że wszystkie przykłady robione są za pomocą terminalu Git Bash na Windows’ie

Wspomnę krótko o konfiguracji a następnie przejdę do konkretnych rzeczy.

Aby zacząć imprezę trzeba założyć konto na Openshift.

https://www.openshift.com/

Robimy signup, potwierdzamy założenie konta. akceptujemy warunki i do dzieła:

  1. W pierwszej kolejności warto zdefiniować namespace  pod adresem
    https://openshift.redhat.com/app/console/settings
    załóżmy, że wybrałem przemekb więc link do aplikacji np: my_app którą stworze na Openshift będzie wyglądał tak:
    my_app-przemekb.rhcloud.com
    Warto zaznaczyć, że namespace musi być unikalny więc trzeba się pogodzić z tym, że wiele nazw może być odrzuconych
    Oczywiście miało być o konsolce więc jak już mamy zainstalowany rch tool (punkt3) wtedy wystarczy

    rhc domain create przemekb

    namespace można usunąć poleceniem  delete przemekb lub zmienić poleceniem update staraNazwa nowaNazwa – ale warto pamiętać, że jak już mamy zdeployowane aplikacje to mogą się pojawić problemy z linkami

  2. Należy dodać na Openshift’cie public key więc połączenia SSH będą możliwe
    (ops! kolejny spory temat)
    https://www.openshift.com/developers/remote-access
    W skrócie jeśli na kompie w lokacji naszego użytkownika znajduje się już folder .ssh a w nim plik z rozszerzeniem .pub należy skopiować jego zawartość i wkleić na stronie z ustawieniami.   Jeśli nie mamy klucza trzeba go wygenerować.
  3. Następnie trzeba zainstalować ichniego toola konsolowego rch.
    Aby tego dokonać należy posiadać Ruby – instalacja Ruby to temat na osobnego posta więc tu tylko wspomnę, że moja wersja to:

    ruby --version
    ruby 2.0.0p0 (2013-02-24) [i386-mingw32]
Jak już mamy zainstalowanego toola  rhc to można startować z robieniem fajnych rzeczy.
  1. Na początek zmiana userów – dostajemy tylko trzy cardrige do wykorzystania więc często tworzy się kolejne konto do testów. Korzystając z rhc pozostajemy domyślnie zalogowani na danym koncie – ale nie ma problemu aby przełączyć się na nowe konto:
    rhc setup -l user@gmail.com

    Zostaniemy grzecznie poproszeni o hasło. Po zalogowaniu możliwe jest pytanie o token dzięki któremu nie trzeba będzie używać hasła.

  2. Aplikacje można stworzyć przez web klienta lub konsolke. Oto przykład z konsolki – javowa apka na jboss’ie :
    rhc app create myapp jbossas-7

    Tworząc apke przez konsolke automatycznine tworzone jest repo z nazwą apki w bieżącym katalogu konsolki.

  3. Usunięcie jest równie proste
    rhc app delete myapp --confirm
  4. Do projektu maven’owego dodajemy profil openshift gdyż z tym profilem będzie budowana nasza apka po wrzuceniu kodziku na openshift’owe repo (przed tagiem </projects> koniecznie w tagu <profiles></profiles>)
     <profile>
             <!-- When built in OpenShift the 'openshift' profile will be used when invoking mvn. -->
             <!-- Use this profile for any OpenShift specific customization your app will need. -->
             <!-- By default that is to put the resulting archive into the 'deployments' folder. -->
             <!-- http://maven.apache.org/guides/mini/guide-building-for-different-environments.html -->
             <id>openshift</id>
             <build>
                <plugins>
                   <plugin>
                      <artifactId>maven-war-plugin</artifactId>
                      <version>2.1.1</version>
                      <configuration>
                         <outputDirectory>deployments</outputDirectory>
                         <warName>ROOT</warName>
                      </configuration>
                   </plugin>
                </plugins>
             </build>
          </profile>
  5. Dodanie projektu z Github do repo (musimy znajdować się w katalogu repo) :
    #usunięcie default'owego poma
    git rm -rf src/ pom.xml
    git commit -am "removed default files";
    
    #dodanie repo z Github i skopiowanie kodu
    git remote add myapp -m master git://github.com/shekhargulati/notebook-part1.git
    git pull -s recursive -X theirs notebook master
    
    #po pushu apka zostanie automatycznie zdeployowana
    git push
  6. Dodanie poprzez wrzucenie pliku .war – tu należy pamiętać, że wrzucając plik do repo naszej aplikacji należy zmienić jego nazwe na ROOT.war
    #katalog z projektem maven'owym
    cd c:/Work/Projects/my_app
    
    #zbudowanie apki
    mvn clean install -Dspring.profile.active="testing"
    
    #kopia do katalogu z ROOT.war projektu openshift'owego
    cp c:/Work/Projects/my_app/target/my_app.war  c:/Workspace/Projects/my_openshift_app/webaps
    
    # W katalogu openshift'owym usuwamy ROOT.war
    cd c:/Work/Projects/my_openshift_app/webapps/
    rm ROOT.war
    
    # zmieniamy nazwę naszej warki
    mv my_app.war ROOT.war
    
    # dodajemy, commitujemy i puszujemy
    git add -A
    git commit -m "ROOT.war added"
    git push

W następnym poście bliżej przyjrzę się wrzuceniu konkretnego repo z GitHub na Openshift oraz podpięciu budowania apki na Jenkins CI http://przemek.yum.pl/openshift-2-buduj-w-chmurze-z-jenkins/

No i zapraszam do lektury dokumentacji Openshift bo jest tam całkiem sporo ciekawych rzeczy  https://access.redhat.com/site/documentation/en-US/OpenShift/2.0/html-single/User_Guide/index.html