CoreOS Playground With PXE – Introduction [1/5]

CoreOS Playground With PXE

CoreOS is an open-source lightweight operating system based on the Linux kernel and designed for providing infrastructure to clustered deployments and it supports Docker out of the box.

Would not be great to have a CoreOS playground to experiment all mighty stuffs this OS promises? Well, it would, at least for me, and here I’d like to share with you how it is possible to create such environment.

The main objective is to come up with a system running on a single PC that allows a developer to easily run experiments involving CoreOS. Here above there’s a list of things I would like to be able to accomplish with this CoreOS playground.

  • Quickly set up a properly configured CoreOS machine and run Docker containers on it.
  • Quickly bring up additional CoreOS machine to test what happens when a node is added to the cluster.
  • Easily discard an entire cluster to try a new configurations.

To do that, I’m going to set a virtual machine not powered by CoreOS. It will act as a router connecting a NAT network on one side, to provide Internet access, and a CoreOS network on the other.

coreos-playground-network

 

On top of that, this machine will provide DHCP and CoreOS via PXE. This way CoreOS will be installed automatically through PXE. I’ll also set up an empty virtual machine properly configured for lan boot. This way, adding a CoreOS node to the cluster will be just a matter of cloning and starting the template machine. As you probably know, a CoreOS installation can be configured providing a reference to a “cloud-config” file. I’ll set up apache on the router to provide such file to the starting CoreOS nodes through HTTP. The following schema depicts the boot process from a logical point of view.

coreos-playground-pxe

I’m going to use VirtualBox to run the machine and Lubuntu for the Playground Server, even though I’m trying to provide as much command line as I can, so it should be all reasonably adaptable to other environments too.

This is just the first installment of this series. If you are interested, stay tuned for the next posts. I’ll show you how to implement the idea presented here.

T2S is finally online

Unmissable Resources

ToughtWorks Tecnology Radar

Unmissable Tools

On Line

  • Mega.nz
    • Plenty of online space to share big files with colleagues. Priceless when you have to send a 2Gb file to a client.
    • https://mega.nz
  • Reg Ex Pal
  • Encryptomatic
    • Are you a GMail user, unable to open attached emails in .eml format, used by Outlook ? Here it’s a quick converter. Just upload the .eml file. It gives you also the possibility to access files that were originally attached into the .eml message.
    • https://www.encryptomatic.com/viewer/
  • Trello
    • A quick and intuitive tool to track activities based on dashboards that you can customize as you prefer. Premium features are available but the free account is powerful enough to use it in your project.
    • https://trello.com/
  • BPMN.io
  • xip.io
    • Uno speciale “domain name” che fornisce wildcard DNS per ogni indirizzo IP.
    • http://xip.io/

Off Line

 

Indirect Input & Output in Unit Testing

Un test unitario definisce un particolare scenario di funzionamento di un unica “unità” che può essere definita come: system under test (SUT), object under test o unit under test, proprio per sottolineare la focalizzazione di cui è oggetto nel test.

 

Per eseguire il SUT nello scenario desiderato è necessario fornirgli un input, cioè l’insieme di informazioni che stimolano la funzionalità in via di definizione attraverso il test unitario. l’output comprende tutte le informazioni restituite dal SUT a seguito alla stimolazione, e su queste sono espressi i vincoli e le attese del test unitario.

 

Raramente, però, un oggetto può portare a termine il proprio compito in perfetto isolamento; il più delle volte esso necessita di collaboratori. L’output dei collaboratori rappresenta per il SUT una forma di input, meglio descritto come input indiretto. Si noti che a parità di input, l’output del SUT dipenderà dall’input indiretto proveniente dai collaboratori.

 

Un test unitario dovrebbe anche definire quali siano le ripercussioni il SUT deve avere sui collaboratori nello scenario eseguito. Tali ripercussioni sono l’indirect output del SUT e possono anch’esse essere oggetto di verifica da parte del test unitario.

indirect_input_output

Si immagini ad una comune applicazione web che permetta ai nuovi utenti di registrarsi fornendo email e password. Se la registrazione va a buon fine, il nuovo utente riceve all’indirizzo di posta dichiarato una email di conferma.

Il processo di registrazione è gestito da un oggetto di tipo RegistrationController che utilizza due collaboratori:

  • un’istanza di UserRepository, servizio che incapsula l’accesso al database degli utenti permettendo di crearne di nuovi e di verificare se un’email sia già utilizzata;
  • un’istanza di Notifier, servizio che permette di inviare email di conferma.

Si ipotizzi di impostare il test unitario che specifichi il comportamento di RegistrationController in caso di registrazione di un nuovo utente con username ancora non utilizzato. Sommariamente lo scenario che si vuole sia verificato dal SUT è il seguente:

  1. Dati…
    1. uno UserRepository (collaborator) che ancora non ha censito alcun utente (e che quindi fornirà un indirect input rappresentante l’assenza di alcun utente),
    2. un Notifier (collaborator),
    3. un RegistrationController (SUT) che usa i precedenti oggetti come collaborator,
  2. quando…
    1. si invoca il metodo newRegistration() di RegistrationController fornendo un’email e una password (stimolazione del SUT)
  3. deve accadere che…
    1. newRegistration() restituisca la stringa “registration_ok” (verifica dell’output)
    2. RegistrationController invochi il metodo sendConfirmationEmail() di Notifier, passando come email la stessa usata per registrarsi (verifica dell’indirect output)

 

Ovviamente questo è solo uno dei vari Test Unitari che andrebbero definiti. Lo scopo in questo caso è tuttavia quello di focalizzare l’attenzione su due punti.

  1. l’output del SUT, verificato al passo 3a) dipende anche dall’indirect input fornito dal collaboratore definito al punto 1a).
  2. Non solo un test unitario deve verificare l’output del SUT, ma anche le ripercussioni che il SUT ha sugli altri collaboratori.

 

Sia impostare l’indirect input che verificare l’indirect output sono due attività che possono essere realizzate seguendo diversi stili ed utilizzando diverse tecnologie, ma questo è materiale per un altro post.
Questi e altri concetti, esempi ed esercizi sono presentati in dettaglio nel corso Test Driven Development organizzato dallo Studio Ingegneria Demichelis presso la tua Azienda, sul sito dedicato trovi tutte le informazioni, ma per qualsiasi approfondimento contattaci pure.