Deploying Java Applications¶

Java Artifacts¶

Typically, when we’re working on our projects, we’re building and running them locally. We have tools like Gradle and our IntelliJ that help us. These tools make compiling and running our application simple. We won’t have those tools in production, however, so we’ll need to package up our code into an executable JAR file.

A JAR file is a Java archive, which is essentially a ZIP file containing a bunch of compiled Java classes. We could use the javac command to take our source files and build an executable JAR file. However, when the JAR is executed, it also needs to be able to find all the dependencies (for instance, Spring) at runtime in order to use them. We’ll need to build our JAR file using Gradle so that these dependencies are packaged up alongside the compiled Java code that we wrote.

Spring Boot adds a plugin to Gradle that allows us to package up our source code alongside any dependencies, creating a fat JAR that contains compiled versions of our code and all of its dependencies. This JAR file can then be deployed to our server, and run anywhere that has the JVM installed. Try building a fat JAR yourself by running

$ gradle assemble

This created a fat JAR which we can run from the command line with the command:

$ java -jar build/libs/coding-events-0.0.1-SNAPSHOT.jar

Our application is now ready to be run on a remote machine. Our next step is to prepare Cloud Foundry to host our application.

Creating your manifest¶

In order to deploy an application with Cloud Foundry, you first must define what your application is and how it should be run. Cloud Foundry uses a manifest.yml file to manage this configuration. Create a file at the root of the project named manifest.yml. And add the following lines.

applications:
- name: coding-events
  buildpack: java_buildpack
  path: build/libs/coding-events-0.0.1-SNAPSHOT.jar

The name will specify the unique name for our application, in this case coding-events. The buildpack tells Cloud Foundry what type of application this is and how to manage it. The path is where to find our executable project, the fat JAR. If you’re following along with another project, check build/libs/ to find the name of the JAR you just built.

Let’s try and deploy our app using:

$ cf push

This will fail. To find out why, let’s try our hand with a little debugging.

$ cf logs coding-events --recent

Now we can view the recent logs from our app (denoted by the --recent flag). Does anything here look familiar? You’ll see that our app can’t connect to the database, which makes sense, since we haven’t set up a remote database for our app.

Flyway database migration¶

Flyway is a tool that uses SQL scripts to create, change, and migrate database schemas and data. These SQL scripts will live alongside our project and will provide a way for us to easily recreate the structure of our database, as well as make additional changes in the future. Flyway tracks scripts that have been executed and detects new scripts and runs them at startup.

First, we add the following dependency to our build.gradle file, in the dependencies section.

implementation 'org.flywaydb:flyway-core'

Spring Boot will detect this dependency and automatically start using Flyway. We will also need to provide our application with SQL scripts that specify how Flyway should manage our database.

Create a directory in your project called src/main/resources/db/migration and create a file named in this directory named V1__initialize.sql. Note that this file name:

• Starts with a capital V followed by the migration #. Your second migration would start with V2.

• Has two underscores between the version and the rest of the file name.

• Has a descriptive tail that makes it easy to tell what this migration includes. For example, you might name your second migration something like V2__add_user_profile.sql

Flyway will load these alphabetically and apply our changes. Since Flyway keeps track of which migrations it has performed previously, it is important to not change this file once deployed. Instead, to make a change to your database, create a new file using the naming conventions above (e.g. V2__my_new_change.sql).

The easiest way to create our initialization script is to export our existing coding-events schema. To do this, open MySQL Workbench, select our database, and choose Server > Data Export. Customize the export by selecting:

1. The coding-events database from the Schema pane.

2. All tables in the Schema Objects pane.

3. Dump Structure Only from the center dropdown.

4. Export to Self-Contained File from the Export Options pane.

5. Both checkboxes at the bottom: Create Dump in a Single Transaction and Include Create Schema.

Exporting database schema from MySQL Server¶

Copy the contents of this SQL file into your V1__initialize.sql file. This will include any test data you have already created, so you may want to clean up any INSERT statements if you’d like to start with a clean slate.

An example V1__initalize.sql might look like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

CREATE DATABASE  IF NOT EXISTS `coding_events` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;
USE `coding_events`;
-- MySQL dump 10.13  Distrib 8.0.18, for macos10.14 (x86_64)
--
-- Host: localhost    Database: coding_events
-- ------------------------------------------------------
-- Server version    8.0.18

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!50503 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `event`
--

DROP TABLE IF EXISTS `event`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `event` (
`id` int(11) NOT NULL,
`name` varchar(50) DEFAULT NULL,
`event_category_id` int(11) NOT NULL,
`event_details_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
KEY `FKnk9w760hnelms32e9oqecw6ru` (`event_category_id`),
KEY `FKons5d3ebm4d3233lhlem44ae7` (`event_details_id`),
CONSTRAINT `FKnk9w760hnelms32e9oqecw6ru` FOREIGN KEY (`event_category_id`) REFERENCES `event_category` (`id`),
CONSTRAINT `FKons5d3ebm4d3233lhlem44ae7` FOREIGN KEY (`event_details_id`) REFERENCES `event_details` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Table structure for table `event_category`
--

DROP TABLE IF EXISTS `event_category`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!50503 SET character_set_client = utf8mb4 */;
CREATE TABLE `event_category` (
`id` int(11) NOT NULL,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

-- Remaining tables omitted

Creating a database service¶

Next, let’s configure a service inside Cloud Foundry for our database. Cloud Foundry considers anything that isn’t an application to be a service, and can provide pre-configured services to help speed up deployment. In this case, we want to create a MySQL database service for our application. Pivotal has a database called cleardb, a flavor of MySQL designed for cloud hosting. The spark instance size is free and will be fine for almost all student projects. Creating a service in Cloud Foundry will also manage passwords and inject them into the application. This means that we do not need to check in our database credentials into version control (because we shouldn’t!).

Create a new service:

$ cf create-service cleardb spark coding-events-db

Check running services:

$ cf services

You should see your newly created service displayed but no application tied to it.

Service binding¶

Now you need to attach our application to your service. Cloud Foundry calls this service binding and provides a network connection between the application and the service. This also removes the need for us to manually define and configure our database URLs.

$ cf bind-service coding-events coding-events-db

We can confirm this has been configured by running cf services again, and we should see our app name has been added.

Once this has been established, it does not need to be re-bound when we redeploy.

Adding a service to the manifest¶

Above, we manually configured our service binding for our application. Alternatively, the manifest.yml can bind services as well. Update your manifest.yml to the following:

applications:
- name: coding-events
  buildpack: java_buildpack
  path: build/libs/coding-events-0.0.1-SNAPSHOT.jar
  services:
    - coding-events-db