Selenium

 

Ecco un articolo sull’integrazione con Selenium Test nel Developer Cloud Service, che include un’applicazione di esempio. Trovate l’originale qui.

Enjoy 🙂

This blog entry illustrates how to configure DevCS to run a simple Selenium Test against a very basic web page. Thanks to Nobuhiko Sekiya – Oracle Senior Sales Consultant for his valuable input.

The selenium test java class (EasywebappTest.java) inside the eclipse (OEPE 12.2.1.1) project, easywebapp, will just verify the string shown in the web page (top.jsp). To begin, download the simple eclipse project with selenium test, easywebapp.zip, from the attachment below. Import this project into your eclipse IDE and connect to your DevCS cloud instance. Note: This application was created and tested in DevCS 15.4.5 with deployment to JCS and not JCS-SX. Now you want to push this source to your DevCS project. If you haven’t created a project in DevCS, then do so now. A good tutorial to follow that illustrates creating a project in DevCS, importing an “Existing Project into a Workspace” in OEPE and synchronizing the workspace with DevCS is available on the DevCS Product Page here.

Note: JCS-SX by default has authentication enabled and a login dialog will popup at access. This is not the case with JCS. Therefore in this example, the Selenium test will fail on JCS-SX.

Now for the core of configuring DevCS to run a Selenium Test. This resides in Hudson Build Configurations and Deployment Configurations. Note: You will have to have a successful build of your app before you can set up an automatic deployment profile in that you will have to have a deployable artifact to complete the deployment configuration. Once you’ve successfully built your easywebapp, you create your deployment configuration and then further configure your Hudson easywebapp_build job. You will also create a second build job named easywebapp_selenium and it is set to run whenever easywebapp_build is built. So as you see, there are a few dependencies here and you will have to go back into your build jobs to further configure them as you go through this process.

So here we go and hopefully it all makes sense when we’re finished. Note: If not shown in these images settings are at the default.

Hudson Build Job easywebapp_build
Step 1: Create a new Hudson build job – easywebapp_build
Sel1.png

Step 2: Configure build job Source Control settings
Sel2.png

Step 3: Configure build job Triggers
Sel3.png

Step 4: Configure build job Build Steps
Sel4.png

Step 5: Configure build job Post Build activities. Note: This shows adding the Deploy Task. You won’t be able to add this until after you’ve had a successful build and then created the Deployment Configuration.

Sel5.png

Step 6: Save your configuration and run your build. If successful, you will have a build artifact to work with in creating a deployment profile. Also notice the Add Deploy Task at the bottom of the previous image. You will modify this Hudson build job once you’ve created your deployment profile and add the following information:
Deployment Configuration: easywebapp
Job: easywebapp_build
Artifact: target/easywebapp.war

Step 7: Your Deployment Configuration will be configured as follows and Note: you will have to do this before modifying your Hudson build job easywebapp_build as I outlined at the beginning of Step 6 above. After successfully creating this Deployment configuration, you will modify the Hudson Build Job easywebapp-build as illustrated in Step 6 above.
Configuration Name: easywebapp
Application Name: easywebapp
Java Service: Select your JCS Service that your previously configured. See further reading at the end of this blog entry for details.
Type: On Demand
Job: easywebapp_build
Build: Pick the most recent stable build (Note: the Selenium test will run against the most recent deployment)
Artifact: easywebapp/target/easywebapp.war

Sel7.png

Hudson Build Job easywebapp_selenium
Step 1: Create a new Hudson build job – easywebapp_selenium

Hud1.png
Step 2: Configure build job Source Control settings

Hud2.png

Step 3: Configure build job Triggers and select the build job easywebapp_build

Hud3.png

Step 4: Configure build job Environment Xvfb Screen and Display Name Offset

Hud4.png
Step 5: Configure build job Build Steps. Note: that the environment variables HTTPS_PROXY_HOST and HTTPS_PROXY_PORT are available to Hudson. The baseurl in Properties should be set to your JCS access url (to the JCS load balancer or directly to the managed server). See further reading at the end of this blog entry for details.

Hud5.png
Step 6: Configure build job Post Build activities to see the test results after the build is finished.

Hud6.png

Step 7: Run the Hudson build job easywebapp_build which will build the app, deploy the artifact (.war) to JCS and run the selenium test against JCS. You can validate success via the log files as configured in Step 6 above.

Further information – Configuring DevCS to deploy to JCS
Check out Edi Vaserman’s blog entry on “How to deploy from your Developer Cloud Service to JCS” to learn how to configure your deployment with public and private keys for your environment.

 

Docker, WebLogic e Kitematic

La civiltĂ  occidentale ci rende naturalmente pigri, e quindi siamo affascinati da GUI che sembrano sempre piĂą facili da usare. Lo strumento di amministrazione di Docker sul Mac (e, per quel che ne so, anche su Windows) è – per ora – Kitematic, in beta, che sembra funzionale e sufficientemente completo per scaricare e lanciare immagini Docker dai repositories presenti su hub.docker.com.

Per provare questa visual novelty e mettere da parte l’animo hacker chiudendo il terminale a caratteri, è necessario:

  • Teletrasportarsi su beta.docker.com e prenotare un token (se siete su Mac/Windows)
  • Aspettare pazientemente la mail con il token e il link per il download
  • Invocare Cthulhu (sempre) leggendo “L’ombra venuta dal tempo” di H.P. Lovecraft
  • Installare Docker + Kitematic per Mac/ Windows
  • Chiamare il Malefico Marini e far sorgere in lui un minimo di aspettativa
  • Avviare Kitematic e scegliere un’istanza da provare (casualmente, WebLogic 12.2.1)
  • Assicurarsi di avere banda passante adeguata
  • Allocare 5 minuti del proprio tempo prezioso (non ci vuole di piĂą)
  • VoilĂ .

Oppure dare un occhiata alle istruzioni in movimento qui sotto. Oppure rimanere con la buona, vecchia, immarcescibile command line a fosfori verdi con cui conviviamo da svariati decenni, pensando che se non si è estinta fino ad ora la vedremo anche nel prossimo…

Enjoy 🙂

Meetup DevOps: 31 Maggio 2016

Ciao DevOppers 🙂

Benvenuti al nostro primo Meetup, una sessione pratica sulle tecnologie DevOps di Oracle che includono le componenti Cloud, e parte di un ciclo che prevederĂ  workshops e aggiornamenti.  Ecco l’agenda:

Developer Cloud Service – hands on

– Sviluppo e continuous integration di applicazioni su JEE (Java Cloud Service) – hands on

– Sviluppo e continuous integration di applicazioni su containers (Application Container Cloud Service) – hands on

Vi aspettiamo fiduciosi e trepidanti nella sede Oracle di Via Bombay 1, a Roma (Torrino), zero slides e molta interazione! Potete iscrivervi qui: http://www.meetup.com/Roma-Oracle-DevOps-Channel/events/230984981/

Enjoy 🙂

WLS e domain partitions

Dal sito del Malefico Marini, ecco il suo ultimo post: WebLogic 12.2.1 & Multitenancy 

Definizione:

WebLogic 12.2.1 ha introdotto il concetto di Multitenancy nelle architetture Middleware basate su Application server.

La multi-tenancy si riferisce ad un principio nell’architettura del software o dell’hardware in cui una singola istanza del software viene eseguita su un server, offrendo il proprio servizio a più client (i tenant). Il concetto di multi-tenancy non deve essere confuso con quello di architettura multi-istanza, in cui istanze software separate o sistemi hardware separati sono resi disponibili a diverse organizzazioni. In un’architettura multi-tenant un’applicazione software è progettata per partizionare virtualmente i suoi dati e la sua configurazione, ed ogni tenant opera con una di queste istanze applicative personalizzate.

La multi-tenancy costituisce una conseguenza fondamentale della tecnologia di virtualizzazione, grazie alla quale possiamo concretizzare un approccio multi-tenant sulle risorse infrastrutturali, in quanto si assiste alla creazione di ambienti virtuali logicamente separati sui medesimi componenti fisici condivisi. L’aggettivo virtuale vuole evidenziare come tale tecnologia consenta di costruire una separazione logica delle risorse.

Nonostante il concetto di multi-tenancy indichi che ci sono delle infrastrutture condivise, ciò che fa la differenza è il livello nel quale le risorse diventano multi-tenant, con una infrastruttura Oracle si è multi-tenant sia a livello applicativo che a livello dei dati/DB e, con riferimento al cloud anche a livello Hardware.

Componenti necessari per la Multitenancy in Weblogic 12.2.1:

Per poter configurare ed utilizzare la Multitenancy in Weblogic 12.2.1 è necessario avere solo un JDK 1.8 (consigliato dalla release/patch-set update 65 in su) con il garbage collector G1 configurato.

WLS 12.2.1 sarà in tal modo in grado di rendere “multitenant” la JVM (partizionamento della JVM) e su di essa baserà la sua multitenancy.

L’unione di un tenant su WLS unito ad un tenant su JVM viene chimamato Domain Partition.

Partizionamento della JVM, le Domain Partitions:

Una JVM quando viene eseguita in una Macchina fisica, consumerà, in base al carico,  tutti i core (cpu) presenti su quella macchina.

Per evitare questo problema e con il nuovo HW multicore che si trova sul mercato, solitamente vengono create immagini virtuali, ad ognuna di esse si assegnano risorse HW quali Cpu e Memoria, vi si reinstalla parte del software e vi si esegue almeno una JVM.

Oltre che per suddividere meglio le risorse presenti su una macchina, tali opersazioni risultano necessarie in alcuni contesti applicativi per separare e/o isolare fisicamente e logicamente le applicazioni.

WLS 12.2.1 è in grado di suddividere una singola JVM in piu zone chiamate domain partitions.

Tramite la Console di Amministrazione di WLS 12.2.1, si è in grado di assegnare  la quantità di CPU, Memoria e file descrittori consumabili da ogni Domain Partition.

Ogni domain partition è fisicamente isolata da un’altra ed ha:

  • una o piĂą applicazioni deployate
  • le sue regole di consumo cpu, memoria e file descrittori
  • un suo proprio JNDI, non ci possono essere quindi conflitti se si usano gli stessi nome logici in domain partition differenti
  • il suo web context root
  • le sue librerie ed il suo classloader
  • le sue configurazioni di JMS, JDBC etc
  • il suo sistema di autenticazione

Ne consegue che è possibile deployare una stessa applicazione piu volte su una stessa jvm ma in domain partitions diverse.

Nel caso ad esempio di architetture a microservizi, una stessa applicazione può essere specializzata rideployandola in domain partitions diverse, assegnando ad ognuna di esse un suo datasource ed un suo pluggable database (Oracle DB multitenancy) ed assegnando ad ogni domain partition uno specifico Authentication Provider. In tale modo ogni applicazione avrà un diverso bacino di utenza ed un diverso sistema di persistenza.

Architettura e funzionalitĂ  di WLS 12.2.1 & Domain Partitions:

Slide6

Nella precedente immagine viene rappresentata una tipica architettura basata su Weblogic 12.2.1 con Multitenancy.

Nela caso della presenza di un cluster e di domain partitions configurate, ogni singola jvm di ogni Managed Server del cluster verrĂ  partizionata nella stessa maniera.

Le applicazioni, quindi, saranno in cluster, dentro ogni singola domain partition.

Tramite la console di amministrazione si potranno definire delle policy di resource sharing e di resource consumption.

Ogni regola applicata su una domain partition può attivare degli eventi quali:

  • Notify : l’applicazione di una domain partition sta consumando piu di un primo limite fissato e ne viene data notifica
  • Slow : l’applicazione di una domain partition sta consumando piu di un secondo limite fissato e viene rallentata dal sistema diminuendogli i thread di esecuzione.
  • Shutdown : l’applicazione di una domain partition sta consumando piu di un terzo limite fissato e viene “spenta” dal sistema. E’ infatti possibile fare stop o start di una domain partition senza che le altre ne siano coinvolte

E’ evidente quindi che con un semplice wizard sulla console di Amministrazione si può decidere quante risorse assegnare ad una domain partition ed alla sua (o sue) applicazioni deployate e quindi se una applicazione inizia a dare problemi, può essere disattivata (automaticamente o manualmente) prima che rechi problemi alle altre applicazioni deployate sulla stessa jvm. Inoltre l’applicazione che viene “spenta”, verrà spenta solo su quella partizione dello specifico Managed su cui creava problemi e continuerà a funzionare nel cluster delle altre partizioni sugli altri Managed.

Nel caso di presenza di cluster dinamico e di regole di scale-up (e/o scale-down), per ogni nuovo managed aggiunto la sua jvm verrĂ  automaticamente partizionata e riconfigurata come le precedenti.

Il nuovo bilanciatore software di Oracle denominato Oracle Traffic Director (OTD) viene aggiornato in automatico nel caso di nuove domain partitions create in un dominio.

Grazie a questa funzionalità di autoaggiornamento dell’OTD si può avere la live-migration delle Domain Partitions.

La live-migration delle domain partitions, consente di spostare a caldo le domain partitions configurate su delle jvm, su nuove JVM (sullo stesso o su nuovo HW). Questo consente ad esempio di aggiornare l’HW (o in generale di eseguire operazioni di manutenzione ordinaria e/o straordinaria) senza dare disservizi.

Le domain partitions una volta che sono configurate possono essere esportate in un file zip con un semplice click dalla console di Amministrazione.

In una domain partition esportata è presente oltre che l’applicazione in essa deployata anche tutte le sue configurazioni come ad esempio, JMS, JDBC, Datasources … etc.

E’ ovviamente anche possibile importare uno di questi file zip e replicare quindi con un semplice click una complessa configurazione di una qualsiasi applicazione configurata in precedenza.

L’export e l’import delle domain partitions semplifica e rende immediato il passaggio di applicazioni da on-premise sul cloud, oppure da ambienti di test ad ambienti di produzione.

Vecchie configurazioni di domini Weblogic, dalla versione 10.3.6 in poi, possono essere trasformate in Domain Partitions ed essere importate su WebLogic 12.2.1, tramite il tool D-PCT (Domain to Partition Conversion Tool) scaricabile da Oracle Technology Network.

Benefici delle Architetture basate sulle Domain Partitions:

Oltre a tutti i benefici descritti in precedenza, una configurazione basata su Domain Partitions rispetto ad una equivalente senza Domain Partitions, risulta leggermente piu veloce ma con un lieve incremento di consumo di memoria.

Solitamente si installa meno software ed in un mondo puramente Java si può evitare di installare ambienti di virtualizzazione (risparmio licenze) e si riduce drasticamente il numero di processi running di JVM, con conseguente minor consumo di RAM e CPU.

Piu domini possono essere consolidati in un unico dominio wls 12.2.1, semplificando nel tempo le eventuali operazioni di patching e/o upgrade.