Spring Boot 2.0.0RC1 julkaistu

En ole hetkeen kirjoitellut omaa blogiani, olen pahasti laiminlyönyt sitä ja kirjoitellut firmablogin puolelle englanniksi. En paranna pahoja tapojani vieläkään, mutta linkkaan mehukkaan artikkelini Java 9 moduuleista, jlinkistä, Spring Boot 2.0 versiosta, ja Dockerista, ja miten ihania mikropalveluita niillä saakaan aikaan.

http://dev.solita.fi/2018/01/24/Java9-modules-Spring-Boot-2-Docker.html

Ja tähän tarpeeton kuva koiranpennusta

Ja tähän tarpeeton kuva koiranpennusta

Tänään Spring Boot pääsi 2.0 beta ja snapshot statuksesta eroon, ja julkaistiin release candidate 1. Se tarkoittaa, että rajapinnat on jo melkolailla hyydytetty, ja muutokset tapahtuvat syvemmällä ennen julkaisuversiota. Sen saa Mavenista imaistua mm. näin:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.0.RC1</version>
</parent>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies><repositories>
    <repository>
        <id>spring-milestones</id>
        <name>Spring Milestones</name>
        <url>https://repo.spring.io/libs-milestone</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

Mitä ihmeellistä siinä sitten on? No paljonkin. Itseä kiehtoo ensinnäkin se, että se toimii Java 9 version kanssa suoraan yhteen. Mikään Spring 1.x versio ei toimi, eikä tule toimimaan. Sen lisäksi siellä on mm. reaktiivista ohjelmointimallia tuotu perinteisen service mallin rinnalle, ja turvapuolen asioita möyhitty parempaan suuntaan. Laajempaa tarinointia mikä on uutta löytyy mm:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0.0-RC1-Release-Notes

Java 9 taas on ihanuutta mm. Stream api parannusten, jshellin, ja etenkin modulaarisuuden myötä. Tuossa linkkaamassani dev blogi artikkelissa mm. kuvataan, miten parisataamegaisesta JDK:sta saadaan tiristettyä muutaman kymmenen megaa kooltaan oleva virtuaalikone, joka pyörittää kyllä Spring Boot REST palveluita, mutta omaa paljon vähemmän turhaa kirjastoa ja koodia kuin ennen. Eli vähemmän tietoturvahaavoittuvuuksia, vähemmän levyn ja muistinkäyttöä.

Tuohon kun länttäät päälle Dockerin, aletaan olla jännän äärellä. Jos et tee jo serverlessiä, tuo on pino jolla taas pärjää pitkään.

Alunperin Java versio 8 oli menossa jo kohti elinkaarensa loppua tämän vuoden syyskuussa – mikä olisi tarkoittanut, että esim. tietoturvapäivityksiä ei siihen enää tipu. Mutta mene ja tiedä, joku ehkä tajusi miten iso paukku Java 9 siirtymä voi olla. Joten Java 8 EOL deadlinea lykättiin ja pehmennettiin isosti.

https://blogs.oracle.com/java-platform-group/extension-of-oracle-java-se-8-public-updates-and-java-web-start-support

Eli, Java versiolla 8 voi hyvin räpytellä vielä 2019 tammikuuhun asti, ja miksei pidemmällekin jos tykkää elää vaarallisesti. Tai voi maksaa tuesta Oraclelle tai IBM:lle ja räpytellä vuoteen 2025. Mutta toisaalta Java versioon 9 voi siirtyä vaikka nyt, heti, tänään. Itselläni se on jo ensisijainen JDK koneessa, ja ensisijainen valinta uutta tehdessä.

Eli ehkä tuosta taas vähän mietintöjä potkimaan vuosi 2018 käyntiin. Tietysti katsoessa tulevaisuuteen, Java versio 9 on jo aika legacyä – sehän on jo monella käytössä. Kiinnostaako Java version 15 julkaisuaikataulu ja tuki?

Lähde: https://www.infoq.com/news/2018/01/JavaSupportJan18

Tuosta ehti jo jokunen vääräleuka päättelemään, että turha päivitellä ysiin, kun samantien voi hypätä versioon 11, kun Java 8 tuki päättyy? 😉 Siitä lisää ehkä myöhemmin.

 

 

 

Mainokset

Docker + Java Trixx

Sattuneesta syystä Docker työkalupakin käyttö on itsellä lisääntynyt suorastaan räjähdysmäisesti viime aikoina. Se ei ole aina helppoa, mutta on kyllä palkitsevaa. Kun ensi kertaa saa hallittua kunnon könttiä palveluita parilla komentorivikomennolla, sensijaan että aiemmin seikkaili siellä ja täällä ja saastutti konettaan X kappaleella erilaisia asennuksia… Ja kun aiemmin Vagrant-koneet haukkasivat suurimman osan muistista, IntelliJ loput, ja nyt docker-kontteja voi läiskiä samaan tilaan tusinan.. Niin olen myyty.

Miten kontit juttelevat?

Pari niksiä on tullut opittua – tai oikeastaan luettua manuaalia tarkemmin. Niksi yksi oli, miten saada docker-compose alla docker-palvelut näkemään toisensa? Ratkaisu oli häkellyttävän yksinkertainen: Käytä docker-compose.yml versiota 2.0, tähän tapaan:

version: '2'
 services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

That’s all you need. Versiossa yksi piti linkitellä palveluita, mutta versiossa kaksi oletuksena saman docker-composen osat ovat samassa virtuaaliverkossa. Se tarkoittaa että ne näkevät toisensa suoraan imagen nimen mukaan, esim. jos web haluaa viitata redis-palveluun http protokollalla porttiin 6379, homma hoituu:

http://redis:6379

Tietysti voi olla että ajat palveluita välillä dockerissa, välillä ei. Itse olen havainnut käteväksi Spring Boot sovelluksissa käyttää tähän profiileja, docker-profiili ylikirjoittaa tarvittavat url viitteet tai vastaavat palvelinviitteet näillä image nameilla, ja perusprofiilissa voi olla että viitataan vielä localhostiin, testiympäristössä voidaan viitata taas ihan muualle.

Dockerin verkkoja voi hallita myös manuaalisesti, ja niistä voi koostaa haluamiaan kokoonpanoja. Kuitenkin, oletuksena siis kontit näkevät toisensa kunhan ovat samassa verkossa. Ei tarvitse avata mitään portteja, ellet sitten halua niihin ulkoapäin viitata.

Miten kontti viittaa hostiin?

Nogh, kaikkea ei saa konttiin vieläkään. Omassa OSX koneessa esim. Windows SQL server ei konttina pyöri, vaikka konttina löytyykin. Docker for Mac antaa vain herjaa, ympäristön pitäisi olla Docker for Windows. Joten joudun tekemään vähemmän ideaalin ratkaisun: Viittaamaan kontista ulospäin.

Onneksi homma hoituu, pitää vain välittää Dockerille tieto siitä ip-osoitteesta jossa host toimii. Se onnistuu esim. näin (OSX kone):

export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)

Dockerfilessa ei voi valitettavasti viedä ihan helpolla sisään env muuttujia, ja oletuksena kontit eivät näe ympäröivien hostien muuttujia. Vaan eipä hätää. Olen itse siirtynyt enenevässä määrin käyttämään docker-composea, ja siellä homma hoituu. Määritellään env muuttuja uudestaan docker-composessa, sitten käytetään sitä java-komentorivillä, viedään todellinen url sisään joka siis viittaa env muuttujan mukaiseen ip-osoitteeseen.

mah_service:
  environment: 
    - HOST_ADDRESS="localhost"
  build: ./mah_service
  command: echo "HOST ADDRESS FOR SQL SERVER $HOST_ADDRESS"
  command: java -Dspring.profiles.active=docker -Dspring.datasource.url="jdbc:jtds:sqlserver://${DOCKERHOST}:1433;DatabaseName=demo" -jar mah_app.jar
  ports:
    - "8080:8080"

Tah-dah, magic happens. Joka tapauksessa, tämä ei ole nätti ratkaisu, vain workaround. Windows dockesterijat eivät tarvitse tätä, vaan käyttävät mieluiten sql serveriä kontissa. Se on aina paras vaihtoehto. Lienee ihan reilua että MacOS puolellakin saa joskus kärvistellä. MS SQL Server for Linuxia ootellessa…

No, siinä tällä kertaa havainnot. Postailen tänne itselleni muistiin jatkossakin niksejä, ettei unohdu. Pian tulee Docker 1.3 ja lisää kivaa… 😉