Naplózás

Szintén egy régi tartozásomat szeretném letudni, méghozzá a naplózó keretrendszerek ismertetését. Az egyik legrégebbi keretrendszer a Log4J, melyet Ceki Gülcü kezdett el fejleszteni. Bizonyos Apache projekteken belül az Apache Commons Logging volt elterjedt. Valamint bekerült naplózás a JDK-ba is, bár kicsit későn reagált az igényekre, a java.util.logging csomagba került, ezért gyakran hívjuk JUL-nak is. Mivel az eltérő library-k eltérő naplózó keretrendszereket definiáltak függőségként, ezért egy alkalmazás fejlesztésekor sajnos több naplózó rendszer is bekerült az alkalmazásba.

Erre a problémára megoldásként hozta létre szintén Ceki Gülcü az SLF4J keretrendszert, mely egy egyszerű API a különböző naplózó keretrendszerek elé. Van egy egyszerű implementációja is (SimpleLogger), de az összes többi keretrendszerhez van illesztése. Mindenképpen érdemes ezt használnunk, hiszen ekkor bármikor cserélhetjük alatta az implementációt.

A Log4J fejlesztése közben tanultak alapján alkotta meg Ceki Gülcü a következő keretrendszert, Logback néven.

Hogy még bonyolultabb legyen a helyzet, kijött a Log4J 2 is, melybe a Logbackből átemeltek pár dolgot, de úgy, hogy közben javítottak is rajta, olyan dolgokat, melyeket a Logbackben nem lehetett annak architektúrális megkötései miatt.

Ebben a posztban nézzük meg pár trükköt a naplózó keretrendszerek használatával kapcsolatban.

(Ennek kapcsán frissítettem egy régi Log4J cikkem, mely elérhető a GitHub-on, valamint van Log4J példa projekt is. A poszt további része természetesen a Logbacket is tárgyalja.)

SonarQube

Bár a SonarQube (korábban egyszerűen csak Sonar) a Java fejlesztés alap eszköztárába tartozik, mégsem írtam még róla, így ezzel a poszttal ezt szeretném bepótolni.

A SonarQube egy olyan komplex szoftverrendszer, mely azt biztosítja, hogy folyamatosan nyomon tudjuk követni a kódunk minőségét (ezt Continuous Code Quality-nek nevezi). A projektünkre statikus kódelemzőket lehet futtatni, melyek elemzik a forráskódot, és annak feltérképezésével próbálnak hibás részeket keresni. (Ezek általában rossz programozási gyakorlatok, az idők során kialakult programozási konvencióknak ellentmondó kódrészletek, vagy tipikus - nem olyan gyakorlott fejlesztők által elkövetett típushibák). A SonarQube-ot először Java nyelvre fejlesztették, de már több, mint húsz programozási nyelvet támogat (, akár egy projekten belül, pl. Java backend, és JavaScript frontend). A SonarQube ezen elemzések eredményét képes hisztorikusan tárolni, így nyomon követhető, hogy idővel hogyan alakul a kódunk minősége. Ezen kívül képes a tesztlefedettséget is tárolni, hogy az automatikus tesztek futása során mely utasítások lettek végrehajva, és mely osztályokra, metódusokra, végrehajtási ágakra nincs tesztünk. Ezeket az információkat nem csak tárolni tudja, hanem egy intuitív felületen képes ezeket meg is jeleníteni. A SonarQube tetszőleges számú projekt adatait képes tárolni és megjeleníteni. Nyílt forráskódú, de licensz is vásárolható, mellyel támogatást kapunk, illetve más nyelvhez is elemzőket.

Nézzük meg, hogy milyen komponensekből áll a SonarQube, hogyan lehet telepíteni, és hogyan elemezhetünk ki vele egy projektet, és hogyan integrálható a fejlesztőeszközünkkel (IDEA, Eclipse és NetBeans).

Issues

Twelve-factor app

Az idén rendezett HOUG 2016 szakmai napon is előadhattam, előadásomat “Üzemeltethető Java alkalmazások” címmel tartottam. Fő téma a Twelve-factor app és a Cloud native volt. Az előadás diái itt megtekinthetőek.

Az előadás húsz perce alatt csak ízelítőt tudtam adni a Twelve-factor app állításaiból, és azok implementációs kérdéseiről Java és főleg Spring Boot környezetben. A Twelve-factor app a Heroku (Platform as a Service) fejlesztőinek ajánlása felhőbe telepíthető alkalmazások fejlesztésére. Azonban én ajánlom ezen útmutatások, legjobb gyakorlatok betartását akár privát környezetben futó egyszerű alkalmazások fejlesztésénél is, ugyanúgy, mint privát vagy publikus felhőben üzemelő microservice architektúrával összerakott rendszerek esetében.

Ebben a posztban kitérek mind a tizenkét pontra, és ismertetem ennek implementációs vetületeit Java, Spring, de főleg Spring Boot környezetben, sőt személyes tapasztalataimat is megosztom. Ettől függetlenül érdemes elolvasnia, azoknak is, akik más környezetben fejlesztenek.

A szakmai napra egy kis példa alkalmazás is készült, mely elérhető GitHubon.

Viczián István a HOUG konferencián

HOUG 2016 szakmai nap meghívó

A HOUG idén is megrendezi őszi szakmai napját. A rendezvény időpontja 2016. október 11., a helyszín Magyar Telekom Székház, 1013 Budapest, Krisztina körút 55. A rendezvényen való részvétel (idén utoljára) ingyenes, de előzetes regisztrációhoz kötött.

A program 9:00-kor kezdődik Dr. Magyar Gábor, a HOUG elnökének megnyitójával, majd Molnár Balázs tart egy előadást “My Life and Cloud” címmel.

Utána a program három szekcióban folytatódik, mint Java & Middleware, BI & Applications, valamint DB & Infrastructure. A részletes programról itt tájékozódhatsz. Lesz szó Oracle Middleware megoldásokról, Oracle Commerce Platformról, WebLogic Serverről, microservice-ekről, JSON-ről, Dockerről, cloudról. Sőt lesz egy Java Coding Workshop is.

Én is adok elő 10:10-től “Üzemeltethető Java alkalmazások” címmel.

Manapság a microservices architektúrák elterjedésével, a felhős megoldások térnyerésével és a DevOps gondolkodásmód divatba jöttével egyre nagyobb az igény arra, hogy a Java alkalmazások könnyen üzemeltethetők legyenek. Bár régóta válasz erre a JMX, nem terjedt el annyira, és az igények túlnőttek rajta.

Az üzemeltetők (különösen, ha az üzemeltetésben fejlesztők is részt vesznek) nem fekete dobozként akarnak tekinteni az alkalmazásra, hanem megfigyelni, sőt, beavatkozni is szeretnének. Látni akarják, hogy az alkalmazás külső kapcsolatai (pl. adatbázis, cache, sorok, webszolgáltatások, stb.) rendben vannak-e. Az alkalmazás milyen paraméterekkel lett elindítva. Különböző értékeket, statisztikákat akarnak kinyerni. Ezeket már meglévő monitoring eszközökbe akarják bekötni. Sőt, support keretében akár éleseben futó alkalmazás működésébe beavatkozni.

Lássuk, hogy erre milyen eszközök vannak, milyen elvárásaink lehetnek, és hogyan tudunk akár saját metrikákat, eseményeket definiálni. Lesz szó RESTful webszolgáltatásokról, Spring Bootról, Metricsről, parancssorról, stb.

Regisztrálj te is, és gyere el!

Spring Cloud Config

Aki régebb óta követi a blogomat, tudhatja, hogy az alkalmazások konfigurációjának kezelése, tárolása és betöltése mindig érdekelt. Mivel manapság Spring környezetben dolgozom, adta magát a Spring Cloud Config. A Pivotal (a Spring mögött álló cég) célja a Spring Boot és a Spring Cloud fejlesztésével az, hogy egy olyan egységes, pehelysúlyú, könnyen használható környezetet adjon a microservices architektúra és a cloud kihívásaira, melyet a Spring Frameworkkel adott a nagyvállalati Java fejlesztés megkönnyítésére, valós alternatívát nyújtva a Java EE helyett. A koncepció ugyanaz, főleg létező eszközök egységes keretbe foglalása, elosztott környezetben elterjedt minták alkalmazása.

A Spring Cloud Config használatával könnyen építhető olyan szerver alkalmazás, mely a konfigurációkat tárolja és szolgálja ki a különböző klienseknek. Ezek tárolása különböző lehet, jelenleg fájlrendszer és verziókezelő rendszer (Subversion, Git), és a klienseket REST interfészen szolgálja ki. Képes a jelszavakat és különböző érzékeny konfigurációkat szimmetrikus vagy aszimmetrikus kódolással tárolni. A megváltozott konfigurációról értesíteni tudja a klienseket. Felhasználói felületet nem biztosít a konfigurációk szerkesztésére, hiszen pl. a Git repository képes az állományok verziózott tárolására, hozzáférés szabályozására, ezen kívül rendkívül jó felületek is vannak hozzá (kezdve a parancssorral). A Config Server ezen kívül bármilyen Spring Boot alkalmazásba könnyen beágyazható. A Config Client egy könyvtár mely szintén Spring Boot alkalmazásokban használható a legegyszerűbben, és képes kapcsolódni a Config Server-hez, és a konfigurációkat onnan betölteni. A Spring Unified Property Managementjébe illeszkedik, használva az Environment és PropertySource absztrakciókat.

Ebben a posztban megmutatom, hogy lehet implementálni egy Spring Boot alkalmazást Config Clientként, hogyan kell felépíteni egy Config Servert. Látunk egy példát a titkosításra. Megnézzük, hogy a szerver képes értesíteni a klienseket Spring Cloud Bus infrastruktúrán keresztül (RabbitMQ-t használva). Sőt a végén a spring-boot-admin grafikus adminisztrációs interfészt is megnézzük Sping Boot alkalmazásokhoz.