Testumgebungen verschiffen

Docker für Integrationstests

Stefan Hildebrandt / @hildebrandttk

perfect development and
test environment?

Not shared!

  • developers
  • manuel testers
  • automated jobs

easy setup





  • simple steps
  • few steps

fully defined

  • clear
  • complete
  • up to date





fast startup

good turnaround

  • for testing
  • for developing









maintainable





flexible scaling

in sync with
source code

Do you know docker?

utilize it for
integration testing!

very low overhead

  • no virtual machine -> no extra kernel
  • no own init services (syslog, network...)
  • process separation (linux process groups)

for integration tests

  • container per test run
  • many containers on one mashine
    • possibility to run full environment

docker host

  • localhost
  • virtual machine/hypervisor
    • docker-machine
    • docker toolbox
    • vagrant
  • remote host (computing center / cloud service)
    • docker-machine

for integration tests

  • without installation on client
    • Windows / OS X clients
  • use existing boxes
    • living in good old enterprises it

docker network

  • inter container network
  • external access via NAT

port mapping

  • images defines possible ports
  • binding on container creation












port mapping

for integration tests

  • seamless integration
  • automatic remapping for parallel runs
    • discovery with docker inspect
docker inspect \
   --format='{{(index (index .NetworkSettings.Ports "8080/tcp") 0).HostPort}}' \
   petclinic_petclinic_1

links

  • inter container communication
    • dummy dns
    • setup of environment variables

links

More options

  • isolated networks with exports
  • multiple isolated networks
  • virtual multi host networks

for integration tests

  • communication between containers without modification
    • full environments
    • mock replacements
  • possibility to test auto discovery and cluster setups
  • scales on multiple hosts

images

  • name
  • tag

for integration tests

  • reference exact versions of containers

layers

  • incremental layers
  • reuse of layers
Application
Application Server
Libs
Base
Application
Libs
Base

pre defined test data

  • extra layer on app image
  • automated creation
  • repeatable build
  • don't use dump files
  • put data to a location within container!
    • easy distribution
    • fast startup
    • fast rollback

examples

Data
Application
Application Server
Libs
Base
Application
Data
Application Server
Libs
Base

copy production (near) database

  • real test data
  • obfuscate
  • reduce to minimum
  • automate

jailer

  • defined database model
    • extraction from existing schema
    • defined-by-hand
  • extraction of full entities from multiple tables
  • custom selects, obfuscating, ...

mysql

  • start mysqld within container
  • create tables
    • mysqldump --no-data <SOURCE_DB>| mysql <TARGET_DB>
  • select and copy data
    • SET FOREIGN_KEY_CHECKS=0;
    • mysql -e "<QUERY>" <SOURCE_DB> | mysql <TARGET_DB>
    • SET FOREIGN_KEY_CHECKS=1;
  • stop mysqld within container

oracle (XE)

  • start oracle-xe within container
  • create db-link
  • copy tables
  • copy data
  • copy constraints, views, triggers, ...
  • drop db-link
  • stop oracle-xe

commit container after (failed) test

modified data, log files
Data
Application
Application Server
Libs
Base

for integration tests

  • fast startup of 'test-ready' containers
  • small network footprint for updates
  • simple debugging

registry

  • central repository for images
  • public

private registry












for integration tests

  • simple distribution

compression

  • registry: compressed
  • network transfer: compressed
  • docker host: uncompressed





for integration tests

  • smaller footprint on network
  • possibility to store more images within registry

shared folders (volume)

  • native (bind) mount
  • high performance
  • image defines possible mount points
  • binding on container creation

Data only container

  • container used by other(s) for data storage

for integration tests

  • data outside off application container
  • simple handling
  • problems to build complex data with docker build

docker-compose

  • tool managing collections of containers
  • definition of runtime parameters
  • live-cycle commands
    • pull
    • build
    • start, up, kill, stop
    • rm, down

for integration tests

  • simple and consistent interface
  • environment in a text file

development with docker

application under development

IDE native environment

  • Setup from vcs (project-Files, maven, gradle, ...)
  • Build and Run within IDE
  • fast setup
  • easy updates
  • good turnaround
  • less complex tests (framework dependant)
  • different environment
  • less realistic ?

remote deployment to container

Deploy / Copy files into a running container
  • fast setup
  • easy updates
  • good turnaround
  • defined environment
  • less ide support
  • remote deployment
  • remote debugging

docker build deployment

build a new image and recreate the container
  • fast setup
  • easy updates
  • defined environment
  • defined deployment
  • remote debugging
  • less ide support
  • bad turnaround

select your balanced setup

  • initial setup
  • build
  • deployment
  • roundtrip
  • debugging

integration test environment

peripheral system

  • best case: add existing image to docker-compose
  • create ci job to build tagged application image
  • complex system setups within containers
  • complexity is within and should stay there
  • mulptiple processes in one container: supervisord

test double systems - make

test double systems - buy

  • soap ui ($)
  • central mocking solutions ($$$)
    • routing, additional credentials, ...
    • don't forget the versions!!!

test infrastructure

Build your environment

Pure Dockerfile

  • simple text dsl
  • static files, no placeholders
  • no maven repo resolver
  • "run, provision, commit" not supported

Maven

  • round about dozen plugins
  • maven properties

#1: Plugin von Roland Huß

  • io.fabric8/docker-maven-plugin
  • build
  • publish
  • run/start
    • await
  • fine grained configuration
  • automatic rebuilds
  • custom network support
  • mac / win(beta) support

#2: Plugin von Wouter Danes

Gradle

  • variable-definitions within Dockerfile's
  • linked multi-container-builds
  • put maven-artifacts into the container

Gradle Docker plugin by Matthias Grüter

Gradle Docker plugin by Benjamin Muschko

  • supports only docker-java
  • many tasks for creating, tagging, deleting and pushing images
  • more complex syntax for those tasks

gradle-dcompose-plugin by Christian Gahlert

  • build support
  • strong docker-compose wrapper

arquillian-cube

Supported use cases

maven gradle cube
build
build run-commit
build ext
distribute
run
run groups
cleanup
remote host
simple run in IDE

Database migration

typical tools

  • flyway
  • liquibase
  • dbdeploy

execution time

  • build-time-provision
  • no additional startup-provision

use cases

  • database migration
  • testing database migration
  • add/modify testdata

login into container

  • docker exec -it <CONTAINER_ID/_NAME> /bin/bash
  • ssh (if required by tools)

Workflow with
CI-Server

create ready to run containers

  • No install jobs on startup
  • No compile jobs on startup
  • No first startup init jobs
  • No liquibase, ...

be aware of caching

Cleanup

  • automate cleanup (container, images, ...)

after failed tests

  • commit, tag and push container

requirements

  • linux (somewhere, docker toolbox: within an hypervisor)
  • disc space
    • hint: dedicated partition for /var/lib/docker
  • disc speed
  • network performance
  • time and passion

conclusions

  • very fast
  • easy distribution
  • easy handling for users
  • download from 127.0.0.1 without authentication
  • cleanup

Examples

Slides

h9t.eu/s/dfi

Stefan Hildebrandt - consulting.hildebrandt.tk

  • Beratung, Coaching und Projektunterstützung
  • Java EE
  • Buildsysteme gradle und maven/ant-Migration
  • Testautomatisierung
  • Coach in agilen Projekten
  • DevOps
Datenschutz Impressum