Spring-Boot

• Opinionated view on Spring
• Lots of autoconfigure magic
• Useful features and defaults for microservices and 12-factor apps
  • Supports externalized configuration using environment variables
  • Easy to use health and metrics endpoints
  • Use of embedded Tomcat allows for-self contained application bundle
• Works well inside a container

@Component
public class MyBean {

    @Value("${foo.bar}")
    private String name;

    // ...

}

$ export FOO_BAR=mobydock

Externalized Configuration

@ConfigurationProperties("foo")
@Component
public class MyBeanProperties {

    private String name;

    public String getName() { ... }

    public void setName(String name) { ... }

}

Externalized Configuration

Type-safe Configuration Properties

• Groovy DSL for build management
• Rich plugin ecosystem
• Allows to use Maven dependencies
• A bit like Maven if Maven was cool ;)

buildscript {
  ext {
    springBootVersion = '1.5.1.RELEASE'
  }
  repositories {
    jcenter()
  }
  dependencies {
    classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
    classpath 'com.bmuschko:gradle-docker-plugin:3.0.5'
  }
}

apply plugin: 'java'
apply plugin: 'org.springframework.boot'

sourceCompatibility = 1.8

repositories {
    jcenter()
}


dependencies {
    compile('org.springframework.boot:spring-boot-starter')
    testCompile('org.springframework.boot:spring-boot-starter-test')
}

apply plugin: 'com.bmuschko.docker-remote-api'

import com.bmuschko.gradle.docker.tasks.image.Dockerfile
import com.bmuschko.gradle.docker.tasks.image.DockerBuildImage

def dockerBuildDir = 'build/docker/'
def applicationJar = "${archivesBaseName}.jar"

task copyJar(type: Copy) {
    dependsOn bootRepackage
    file(dockerBuildDir).mkdirs()
    from "$libsDir/$applicationJar"
    into dockerBuildDir
}

task createDockerfile(type: Dockerfile) {
    dependsOn copyJar
    destFile = project.file(dockerBuildDir + "Dockerfile")

    from 'openjdk:8-jre'
    copyFile(applicationJar, "/")
    entryPoint "sh", "-c", 
      "java \$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /$applicationJar"
}

task buildImage(type: DockerBuildImage) {
    dependsOn createDockerfile
    inputDir = createDockerfile.destFile.parentFile
    tag = 'devops/hello-world'
}

Hands-on!

"Hello World" from a container with externalized configuration

$ docker run \
--rm \
--name "hello-world-test" \
-e "GREETER_NAME=docker-command-line" \
devops/hello-world

$ ./gradlew buildImage

Build your image

(or via IDE...)

Run a container from your image

• Try using different names!
• What happens if you omit the environment variable?

class HelloSpockSpec extends spock.lang.Specification {
  def "length of Spock's and his friends' names"() {
    expect:
    name.size() == length

    where:
    name     | length
    "Spock"  | 5
    "Kirk"   | 4
    "Scotty" | 6
  }
}  

@ContextConfiguration
@SpringBootTest
class ApplicationTests extends Specification {

    def "should boot up"() {
        expect:
        true
    }

}

Hands-On!

Writing Spock tests

• Extend the BookRepositoryTests by a test that ensures that a book without IBAN can't be stored
• Extend the BookRepositoryTests by a test that ensures that a book with IBAN can be found after it was stored

$ git clone https://github.com/devops-gathering/bootiful-book-store.git

$ gradlew check

Run the test suite with:

For better visualized results, run the gradle task from your IDE:

Testcontainers

• Use Docker containers in your JUnit tests 
• Spock extension also available ;)

@Testcontainers
class JpaTests extends Specification {

    @Shared
    PostgreSQLContainer postgresContainer = new PostgreSQLContainer()
            .withDatabaseName("bootiful")
            .withUsername("bootiful")
            .withPassword("secret")

    ...
}

• PostgreSQLContainer will wait until the database is fully operational

Dockerize

• Our bookstore application depends on creating the schema at startup...

• In our integration test, using the PostgreSQLContainer ensures the database is ready.

• But how do we ensure the database is ready in our deployment scenario?

'Correct' answer:

"We don't"

• Rather build applications that can easily recover from network failure
• Rather fail to boot dependent services in a swarm environment
  • service will be restarted until it works
• BUT there are legacy applications...
• ... and more often than not, framework mechanisms don't play nice with that idea

Introducing Dockerize

• Delay your application start until a port is reachable

version: "2"
services:
  db:
    image: postgres
  myservice:
    image: devops/myservice
    depends_on:
      - "db"
    entrypoint:
      - dockerize
      - -wait
      - tcp://db:5432
      - -timeout 
      - 120s
      - java
      - -jar
      - myservice.jar

Installing Dockerize

• In your createDockerfile-task:

task createDockerfile(type: Dockerfile) {
    [...]
	// Install dockerize
	environmentVariable('DOCKERIZE_VERSION', 'v0.3.0')
	runCommand 'apt-get update && apt-get install -y wget'
	runCommand 'wget \
 https://github.com/jwilder/dockerize/releases/download/$DOCKERIZE_VERSION/dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \
    		&& tar -C /usr/local/bin -xzvf dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz \
    		&& rm dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz'
    [...]
}

https://github.com/jwilder/dockerize#installation