DEV Community: Malek Ramdani

When Java meet GKE

Malek Ramdani — Sun, 07 May 2023 05:15:14 +0000

Introduction

This post is the third and last one in our series 'When Java Meets...'. In the first two posts, we learned how to deploy a Java application with Docker and then with Kubernetes in a local environment.

In this article, we will learn how to deploy our Java application on GKE, which is a managed service for deploying and managing containerized applications on Google Cloud Platform.

What is GKE ?

GKE stands for Google Kubernetes Engine, which is a managed service for deploying and managing containerized applications on Google Cloud Platform. It is a fully managed platform that allows you to easily run and manage containerized applications in the cloud.

As we explained in the previous posts, Kubernetes is an open-source container orchestration system that allows you to deploy, scale, and manage containerized applications. GKE provides a fully managed Kubernetes environment that is optimized for running containerized applications on Google Cloud Platform. With GKE, you can focus on your application development while Google manages the underlying infrastructure.

GKE provides features such as automatic scaling, load balancing, and automatic upgrades to ensure your application is always available and running smoothly. It also integrates with other Google Cloud Platform services such as Cloud Storage, Cloud SQL, and Cloud Build, making it easy to build and deploy modern cloud-native applications.

In summary, GKE is a powerful and fully managed platform for deploying and managing containerized applications on Google Cloud Platform using Kubernetes.

Environment configuration

Before we can create a GKE cluster and deploy our application, The steps below needs to be performed:

Before to start, please ensure that you already have a GCP account, if not you can a create a GCP free tier account, which will be sufficient for this tutorial.

Install gcloud CLI

Google Cloud (gcloud) CLI is a tool we can use to interact with various Google Cloud Platform services from the command line, such as Google Compute Engine, Google Kubernetes Engine, and Google Cloud Storage.

For example, you can use the gcloud CLI to create and manage the following:

Compute Engine virtual machine instances and other resources
Cloud SQL instances
Google Kubernetes Engine clusters
Dataproc clusters and jobs
Cloud DNS managed zones and record sets
Cloud Deployment Manager deployments

gcloud also provides access to additional tools and commands for managing Google Cloud Platform services, including authentication and authorization, configuration management, and resource management.

The installation below was done on a 64-bit Ubuntu 20.04.1 LTS. your environment may differ, you can find the installation types for other platfroms in this link : https://cloud.google.com/sdk/docs/install

First download the gcloud archive and extract the content of
the file:

curl -O 
https://dl.google.com/dl/cloudsdk/channels/rapid/downloads
/google-cloud-cli-429.0.0-linux-x86_64.tar.gz

tar -xf google-cloud-cli-429.0.0-linux-x86_64.tar.gz

Run the installation script from the root of the folder you
extracted to using the following command:
```
./google-cloud-sdk/install.sh
```
Once the installation is done, run the gcloud init command:
```
gcloud init
```
gcloud init performs the following setup steps:
- Authorizes the gcloud CLI to use your user account credentials to access Google Cloud, or lets you select an account if you have previously authorized access
- Sets up a gcloud CLI configuration and sets a base set of properties, including the active account from the step above, the current project, and if applicable, the default Compute Engine region and zone
When gcloud init finishes, it prints the properties in the
active configuration to the terminal::
```
gcloud init    
[compute]
region = us-east1
zone = us-east1-b
[core]
account = user@google.com
disable_usage_reporting = False
project = example-project```
```

Now we are ready to create our project dedicated to our Players application.

Create a new project in GCP

To create a new project run this command:

gcloud projects create players-app --name="players-app project" --labels=type=tuto

Once is done, activate the new project configuration by running this command:
```
gcloud config configurations create playersapp --account your-gcp-account --project players-app
gcloud config configurations activate playersapp
```
This command will create a new configuration and make it active. If you want to see the configuration list, run this command:
```
gcloud config configurations list
```
Set the default region and zone for your project. This way you will not need to type those info when creating the GKE cluster and other resources:
```
gcloud compute project-info add-metadata --metadata google-compute-default-region=europe-west1,google-compute-default-zone=europe-west1-b
```
If you want to do a check, you should see the keys google-compute-default-region and google-compute-default-zone with the region entered above after you execute this command:
```
gcloud compute project-info describe --project players-app
```
We are almost there, to avoid having an error message when creating our GKE cluster, we need to activate some GCP services by running this command:
```
gcloud services enable compute.googleapis.com container.googleapis.com
```

Play with GKE!

Create the GKE cluster

Now that everything is ready, we can create a GKE cluster that we will call players-gke by executing this command:

gcloud container clusters create players-gke --release-channel None

We can check in the GCP web console that our GKE cluster is now up and running:

As simple as that! now we have a Kubernetes cluster ready to host our application!

Install kubectl tool

To interact with our cluster we need to use kubectl. in your shell terminal run this command:

gcloud components install kubectl

To verify that kubectl is installed run:

kubectl version

Run this command to update kubectl configuration:

gcloud container clusters get-credentials players-gke \
    --region=northamerica-northeast2

Verify that your configuration is done properly by typing this command :

$ kubectl get namespaces
NAME              STATUS   AGE
default           Active   40m
kube-node-lease   Active   40m
kube-public       Active   40m
kube-system       Active   40m

Alright, let's deploy our application on our newly created cluster!

Deploy players app on GKE

In the same way we did on the local Kubernetes cluster in the previous post, we will use kubectl appl to deploy our application, using two yaml files that you can find in this GitHub repo, one for the SpringBoot application and the other for the postgres database :

$ kubectl apply -f postgres.yaml 
deployment.apps/playersdb created
service/playersdb created
$ kubectl apply -f deployment.yaml 
deployment.apps/players created
service/players created

Now our workload is deployed and we can see in the cloud console:

We can also see the services that has been created:

Test our application

To test our application we need to make a REST api call to the players app which is exposed through a Node port.

First we need to view the service, the output shows a nodePort value:

$ kubectl get service players --output yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"ingress":true}'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"creationTimestamp":null,"labels":{"app":"players"},"name":"players","namespace":"default"},"spec":{"ports":[{"port":8080,"protocol":"TCP","targetPort":8080}],"selector":{"app":"players"},"type":"NodePort"},"status":{"loadBalancer":{}}}
  creationTimestamp: "2023-05-08T03:12:39Z"
  labels:
    app: players
  name: players
  namespace: default
  resourceVersion: "27799"
  uid: a719a733-f2d9-4a42-9a97-f49af11d62fb
spec:
  clusterIP: 10.72.9.232
  clusterIPs:
  - 10.72.9.232
  externalTrafficPolicy: Cluster
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - nodePort: 31538
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: players
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

We can see above that the nodePort value is 31538. We create a firewall rule to allow TCP traffic on your node port:

gcloud compute firewall-rules create test-node-port --allow tcp:31538

We need alos to find the external IP address of one of our nodes :

$ kubectl get nodes --output wide
NAME                                         STATUS   ROLES    AGE   VERSION            INTERNAL-IP   EXTERNAL-IP      OS-IMAGE                             KERNEL-VERSION   CONTAINER-RUNTIME
gke-players-gke-default-pool-5fe50b35-6l48   Ready    <none>   65m   v1.25.7-gke.1000   10.188.0.9    34.130.171.114   Container-Optimized OS from Google   5.15.65+         containerd://1.6.18
gke-players-gke-default-pool-5fe50b35-j7dw   Ready    <none>   65m   v1.25.7-gke.1000   10.188.0.8    34.130.43.212    Container-Optimized OS from Google   5.15.65+         containerd://1.6.18
gke-players-gke-default-pool-5fe50b35-jn77   Ready    <none>   65m   v1.25.7-gke.1000   10.188.0.7    34.130.245.5     Container-Optimized OS from Google   5.15.65+         containerd://1.6.18

Finally we can start testing our service by sending our API call using on of the external node IPs in our URL:

$ curl -i --location --request GET '34.130.43.212:31538/api/player/v1/test'
HTTP/1.1 200 
Content-Type: text/plain;charset=UTF-8
Content-Length: 14
Date: Mon, 08 May 2023 03:40:52 GMT

This is a test

Great! We can see that our application is responding, now we can make another api calls to add players and get the list of them as well:

$ curl -i --location --request POST 'http://34.130.171.114:31538/api/player/v1/add' \
--header 'Content-Type: application/json' \
--data-raw '{
    "firstName": "Riyad",
    "lastName": "Mahrez",
    "team": "Manchester City",
    "position": "RW"
}'

HTTP/1.1 200 
Content-Type: application/json
Transfer-Encoding: chunked
Date: Mon, 08 May 2023 03:43:54 GMT

{"id":1,"firstName":"Riyad","lastName":"Mahrez","team":"Manchester City","position":"RW"}

$ curl -i --location --request POST 'http://34.130.171.114:31538/api/player/v1/add' \
--header 'Content-Type: application/json' \
--data-raw '{
    "firstName": "Ismail",
    "lastName": "Bennacer",
    "team": "AC Milan",
    "position": "CM"
}'

{"id":2,"firstName":"Ismail","lastName":"Bennacer","team":"AC Milan","position":"CM"}

$ curl -i --location --request GET 'http://34.130.245.5:31538/api/player/v1/list'

HTTP/1.1 200 
Content-Type: application/json
Transfer-Encoding: chunked
Date: Mon, 08 May 2023 03:47:42 GMT

[{"id":1,"firstName":"Riyad","lastName":"Mahrez","team":"Manchester City","position":"RW"},{"id":2,"firstName":"Ismail","lastName":"Bennacer","team":"AC Milan","position":"CM"}]

Congratulations! You've made it to the end of our practical guide on containerizing a Java application and deploying it in various environments using Docker, a local Kubernetes cluster, and a public cloud Kubernetes cluster. By following the steps outlined in this series of posts, you should now have a solid understanding of the containerization process and how to deploy your application to a Kubernetes cluster.

We hope this guide has been helpful in your journey towards mastering containerization and Kubernetes deployment. Remember, this is just the beginning, and there is always more to learn and explore in this ever-evolving field.

Thank you for reading, and happy containerizing!

When Java meet Docker... Part II kubernetes

Malek Ramdani — Tue, 18 Apr 2023 04:05:30 +0000

In the previous post When Java Meets Docker Part I, we covered the basics of Cloud-Native, Docker, and how to deploy a simple Java application. In this post, we'll take it a step further. First, we'll implement a more sophisticated application using the Spring Boot framework. Then, we'll deploy this application in a more efficient and practical way using Docker Compose. Finally, we'll go even further by deploying it in Kubernetes on our local environment using Minikube. Let's start !

The architecture of our solution remains the same: a Java application that connects to a database. However, this time, we're going to have a Spring Boot application that exposes REST APIs. We'll have two API endpoints: POST http://myserver:8080/api/player/v1/add to create a new player and save it into our database, and GET http://myserver:8080/api/player/v1/list to retrieve the list of players we have in our database. Additionally, we'll have an API for testing purposes.

As the objective of this post is not Java development itself, we won't go into too much detail about how to develop an application in Spring Boot.

Players app v2

For our updated "Players" application, we will be able to add and view the list of players through REST APIs. To achieve this, we'll have two API endpoints. The first will create a new player and save it into our database: POST http://myserver:8080/api/player/v1/add. The second will retrieve the list of players we have in our database: GET http://myserver:8080/api/player/v1/list.

In summary, our application should now look like this:

In this solution we will not need to create a table in the database, springboot will take care of it. To achieve this we have put the property spring.jpa.hibernate.ddl-auto=create-drop in our properties file, which will indicate to our application to drop and create the table based on the class (entity) Player.java at every start up.

The code source of the application can be found in this GitHub repo : https://github.com/MalikooR/players_spring_boot/tree/main/players

Push docker image to docker hub

Before we start using Docker Compose, let's containerize our Spring Boot application and push it to Docker Hub. This will allow us to use the container at different stages of this post. Creating the container is a simple process and follows the same steps we covered in the previous post.

Once we've executed the Maven package goal on our application, a .jar file will be created in the target folder. We'll then copy this jar file to a new folder and create a Dockerfile with the following content:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=players.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

And run this command :

docker build -t malikoo/players:1.0 .

Where malikoo is the dockerhub user, players is the repository name and the number after the semicolon is the image tag.

Now we can push our image into docker hub simply by executing the command below :

docker push malikoo/players:1.0

Before running the docker push command, you need to run docker login and use your docker hub credentials to connect to the registry.

Docker compose

In this step we are going to deploy our application using docker compose. Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

In our case our we will have two services, our java application running on playersapp container exposing a service on the port 8080 which will be mapped to the port 8080 of the host machine and the Postgres db playersdb that will expose a service on a port 5432 mapped to the port 5555 of the host machine.
create a yaml file and past the following :

services:
  web:
    container_name: playersapp
    depends_on:
      - post
    image: malikoo/players:1.0
    ports:
      - "8080:8080"
    environment:
      POSTGRES_URL: playersdb:5432/testdb
  post:
    image: postgres
    container_name: playersdb
    ports:
      - "5555:5432"
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: testdb

Note that the default compose file name is docker-compose.yaml, with this filename you won't need to specify the file to docker compose as long as it's in the current path. Otherwise, you should use -f option to specify your custom file name.

Now that our docker compose file is ready, all we need is to run this command :

docker compose up

We can test that the process went well by checking this address:

$ curl --location --request GET 'localhost:8080/api/player/v1/test'
Output: This is a test

If you can see the test message, it means that now our Spring-boot application is running and listening to the port 8080, now let's try to make some API call and confirm that our application is talking properly to our database.
let's run those two API calls to add two players :

$ curl  -i --location --request POST 'localhost:8080/api/player/v1/add' \
 --header 'Content-Type: application/json' \
 --data-raw '{
         "firstName": "Roberto",
         "lastName": "Boutabout",
         "team":"Real Madrid",
         "position":"CF"
     }'
HTTP/1.1 200
Content-Type: application/json
Transfer-Encoding: chunked
Date: Wed, 09 Feb 2022 19:18:58 GMT

{"id":1,"firstName":"Roberto","lastname":"Boutabout","team":"Real Madrid","position":"CF"}


$ curl -i --location --request POST 'localhost:8080/api/player/v1/add' \
 --header 'Content-Type: application/json' \
 --data-raw '{
         "firstName": "Mahmoud",
         "lastName": "Donadoni",
         "team":"FC Barcelona",
         "position":"LW"
     }'
HTTP/1.1 200
Content-Type: application/json
Transfer-Encoding: chunked
Date: Wed, 09 Feb 2022 19:19:48 GMT

{"id":2,"firstName":"Mahmoud","lastname":"Donadoni","team":"FC Barcelona","position":"LW"}

We can see above that the two players have been added with a unique Id.
Now, let's try to get the list of our players :

$ curl -i --location --request GET 'localhost:8080/api/player/v1/list'
HTTP/1.1 200
Content-Type: application/json
Transfer-Encoding: chunked
Date: Wed, 09 Feb 2022 19:21:45 GMT

[{"id":1,"firstName":"Roberto","lastname":"Boutabout","team":"Real Madrid","position":"CF"},{"id":2,"firstName":"Mahmoud","lastname":"Donadoni","team":"FC Barcelona","position":"LW"},]

Fine, at this stage we already see that our deployment is more elegant and simpler, but what if our application have 20, 30 or maybe 100 containers, here an ORCHESTRATOR comes into the picture, and this is exactly what Kubernetes do.

Kuberenetes

Kubernetes, also known as k8s, is an open-source container orchestration platform used for deploying, scaling, and managing containerized applications. It provides a way to automate the deployment, scaling, and management of containerized applications, allowing developers to focus on writing code without worrying about the underlying infrastructure. Kubernetes provides a platform for running and managing containers, with features like load balancing, automatic scaling, self-healing, and rolling updates, making it easier for developers to deploy and manage their applications. It is commonly used in cloud-native environments, allowing applications to be deployed and managed in a consistent way across multiple cloud providers and on-premises environments.

Environment

For this tutorial we will use minikube. Minikube is an open-source tool that enables us to set up a single-node Kubernetes cluster on our local machine.
The installation is pretty simple, all you have to do is to follow the steps from the official doc in this link : https://minikube.sigs.k8s.io/docs/start/
Once the installation is done, run minikube start and here you go, now you have a local Kubernetes cluster on your machine.

Workload

As defined in the official Kubernetes documentation (https://kubernetes.io/docs/home/), a workload is an application running on Kubernetes. Whether your workload is a single component or several components that work together, in Kubernetes, you run it inside a set of pods. In Kubernetes, a Pod represents a set of running containers on your cluster.

In our case, we will create manifests for the following Kubernetes objects: two Deployments and two Services. The Deployments will roll out ReplicaSets, which in turn will create Pods containing the Application and Database containers. One Service will expose the database port, allowing the application to communicate with it. The second Service will expose the application endpoints we will call.

Manifests

One of the core principles of Kubernetes is the concept of desired state, where you define the state you want your application to be in, and Kubernetes takes care of the rest.

In Kubernetes, the desired state is defined using a declarative approach, where you specify the desired configuration of your application in a YAML or JSON file called a manifest. This manifest includes information about the application's containers, networking, volumes, and other resources required to run the application.

When you deploys the manifest to Kubernetes, Kubernetes compares the desired state to the actual state of the cluster and takes the necessary steps to reconcile any differences. This process is known as the reconciliation loop and is the key to Kubernetes' ability to maintain the desired state of an application.

The reconciliation loop consists of four steps. The first step is to observe the current state of the cluster and compare it to the desired state specified in the manifest. In the second step, Kubernetes determines what actions need to be taken to bring the actual state in line with the desired state. These actions may include creating new resources, updating existing resources, or deleting resources that are no longer needed.

Once Kubernetes has determined the necessary actions, it takes the third step of executing those actions to make the required changes to the cluster. Finally, Kubernetes waits for the changes to take effect and repeats the process to ensure that the actual state of the cluster matches the desired state.

In summary, Kubernetes takes the desired state defined in a manifest file and uses a reconciliation loop to compare it to the actual state of the cluster. It then takes the necessary steps to bring the actual state in line with the desired state and repeats the process to ensure that the application remains in the desired state.

Four our solution and for a sake of simplicity we are going to create two manifest files, application.yaml for the application's Deployment and Service objects. And database.yaml for the Database's Deployment and Service objects.

Application.yaml manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: players
  name: players
spec:
  replicas: 1
  selector:
    matchLabels:
      app: players
  strategy: {}
  template:
    metadata:
      labels:
        app: players
    spec:
      containers:
      - image: malikoo/players:2.0
        name: players
        resources: {}
        env:
        - name: POSTGRES_URL
          value: playersdb:5432/testdb
      initContainers:
      - name: init-postgres
        image: postgres:9.6.5
        command: ['sh', '-c', 'until pg_isready -h playersdb -p 5432; do echo waiting for database; sleep 2; done;'] 

apiVersion: v1
kind: Service
metadata:
  labels:
    app: players
  name: players
spec:
  ports:
  - name: 8080-8080
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: players
  type: ClusterIP
status:
  loadBalancer: {}

This manifest defines a Deployment in Kubernetes that creates a single replica of a container based on the Docker image malikoo/players:2.0. The container is named "players".

this manifest creates also a Service that exposes the players pods on port 8080 within the cluster.

Note that we have an init container; this section is used to specify any containers that should run before the main container starts. Our goal here is to wait until the database is up and running before running our Spring Boot application.

Database.yaml manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: playersdb
  name: playersdb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: playersdb
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: playersdb
    spec:
      containers:
      - image: postgres
        name: postgres
        resources: {}
        env:
        - name: POSTGRES_PASSWORD
          value: postgres
        - name: POSTGRES_DB
          value: testdb 
status: {}
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: playersdb
  name: playersdb
spec:
  ports:
  - name: 5432-5432
    port: 5432
    protocol: TCP
    targetPort: 5432
  selector:
    app: playersdb
  type: ClusterIP
status:
  loadBalancer: {}

this manifest creates a Postgres database deployment and a Service that exposes the database within the Kubernetes cluster on the port 5432.

Kubectl Apply

Minikube comes with a built-in kubectl installation. Kubectl is a command-line interface (CLI) tool used to interact with Kubernetes clusters. It allows us to deploy, inspect, and manage applications running on Kubernetes, as well as access and manage cluster resources such as nodes, pods, services, and configurations.

To deploy our solution all we have to do is run those two commands :

kubectl apply -f application.yaml

kubectl apply -f database.yaml

Now we can use kubectl to see the newly created k8s objects :

>kubectl get deployment
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
players     1/1     1            1           11d
playersdb   1/1     1            1           11d

>Kubectl get pods
NAME                         READY   STATUS    RESTARTS   AGE
players-69cc7f875d-4rnph     1/1     Running   0          12m
playersdb-668967cfb5-859hn   1/1     Running   2          11d

>kubectl get services
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    
players      ClusterIP   10.99.208.51    <none>        8080/TCP   
playersdb    ClusterIP   10.100.152.81   <none>        5432/TCP

Great, now our application is up and running, we can test it to confirm that it's working properly.
Before to do test we need to make a port forwarding to be able to access the application, to do this run this command :

 >kubectl port-forward service/players 8080:8080
 Forwarding from 0.0.0.0:8080 -> 8080

Let's do our test :

>curl -i  --request GET 'localhost:8080/api/player/v1/test'
HTTP/1.1 200 
Content-Type: text/plain;charset=UTF-8
Content-Length: 14
Date: Sun, 09 Apr 2023 11:51:42 GMT

This is a test

Congratulations! You have successfully deployed your application on Kubernetes. You can now access your application using the service endpoint the same way we did previously in this tutorial after using docker compose.

So, to wrap up, we can summarize the different steps to go from an application to Kubernetes as follows :

Thank you for following this tutorial, and I hope it was helpful. If you have any questions or feedback, please don't hesitate to reach out.

When Java meet Docker... Part I

Malek Ramdani — Tue, 18 Jan 2022 23:21:16 +0000

In this post, we are going to learn the very basics of how to run a java application inside a Docker container, we will start with a few definitions, and then we will build a small silly Java application which will, at the end of the post, run in a container.

This, will be a first post of a series about Java and Docker, our application will evolve along the series, until we reach the cloud ☁️ !! So let's start the journey ✈️

Cloud-Native

Before we start talking about Docker and Java, let's have a few words about Cloud-Native, a term we hear often in the IT world nowadays. So what cloud-native means ?
Here is how CNCF (Cloud Native Computing Foundation) defines it :

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

In other words, Cloud-Native is a set of principles and technologies we should follow and use to build highly available, scalable, reliable and resilient software, and all of this with speed and agility.

But, isn't cloud, cloud-native ? Well, we need to differentiate between the two, as explained by Cornelia Davis in her book Cloud Native Patterns, when talking about differentiating the cloud-native from the cloud :

the latter is about where, whereas the former is about how and is the really interesting part).

Docker

But what docker have to do with all of this ? Wait, we are almost there 😊, one of the pillar of cloud-native is the containerization, and the most popular software to manage containers and ship applications into it is Docker !!

If the concept of containerization is a decade old in Linux systems (cgroups and kernel namespaces), the emergence of Docker accelerated the use of this technology. A glimpse of docker underlying technology can be found in the official documentation :

Docker is written in the Go programming language and takes advantage of several features of the Linux kernel to deliver its functionality. Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container.

These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace.

What are we going to build

Now that we have the context, we can start working on our Java application and run it in a container later on.

First, we are going to code a very simple application that query a MySQL database and get a list of football (Soccer in North America ) players. Then we will create a jar file from this application and write a dockerfile to create a Docker image and then run container where our application will be executed.

We will also deploy MySQL database in a Docker container, run everything and see the magic.

At the end, our application should looks to something like this :

MySQL Database with Docker

First, let's start with the database, we are going to run a MySQL container with our user and password, and then go inside the container to create our schema, table and some dummy data.
Our schema will have only on table "players" :

Before we run the database container, we need to create a network on which our containers will be running, in fact when containers are created by Docker they are isolated and do not communicate with each other, this why we need to specify that the containers are on the same network in order to enable communication between them.
When we create a new network, Docker by default will create it as a bridge netwrok, to do this let's run this command :

docker network create mynet

the output of this command should be a long alhphanumeric string (f9bc75b98986ac....)
You can type docker network ls and you will see your network newly created, you should see something like this :

Now that we have our network, let's run our MySQL container. For this, we are going to use the official MySQL Docker image, and execute this command :
docker run --name playersdb --network mynet -e MYSQL_ROOT_PASSWORD=1234 -d mysql:latest

The command above will run a container from mysql image docker run with the latest version mysql:latest, the name of the container will be playersdb --name playersdb, the container will run on a network mynet --network mynet, the root password will be '1234' -e MYSQL_ROOT_PASSWORD=1234 (-e is used to determine the environment variables of the container) and the container will run in a detached mode (in the background) -d

Let's check our container now, using docker ps :

Cool, our database container is now up and running, what we need to do now is to connect to our instance and create the schema we will use in our application.
we could have used the port mapping by adding the option -p 3306:3306 in the Docker command above and would have used mysql workbench to manage the database. Instead we will use docker, specifically the "docker exec" command to open a mysql cli session into the container. To do this we need to run this command :
docker exec -it playersdb mysql -uroot -p1234
here we should find ourselves in the mysql cli, now we can copy past the sql code below, it will create a schema playersdb, a user juser*, our table **players as described above and finally insert some data into our db :

CREATE DATABASE `playersdb` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci */ /*!80016 DEFAULT ENCRYPTION='N' */;
CREATE USER 'juser'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON * . * TO 'juser'@'%';
FLUSH PRIVILEGES;

USE playersdb;

CREATE TABLE `players` (
  `id` int DEFAULT NULL,
  `lastname` varchar(255) DEFAULT NULL,
  `firstname` varchar(255) DEFAULT NULL,
  `team` varchar(255) DEFAULT NULL,
  `position` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

INSERT INTO `playersdb`.`players`
(`id`,
`lastname`,
`firstname`,
`team`,
`position`)
VALUES
(1,
'Ryad',
'Boudebouz',
'Algeria',
'RW'),
(2,
'Manuel',
'Ruicosta',
'Portugal',
'CM'),
(3,
'Fernando',
'Redondo',
'Argentina',
'DM'),
(4,
'Ricardo',
'Kaka',
'Brazil',
'CM'),
(5,
'Ronaldo',
'TheOnlyRonaldo',
'Brazil',
'CF'),
(6,
'Paolo',
'Maldini',
'Italy',
'CB');

In order to check if the sql script executed without issue, you can run a select query select * from playersdb.players, the result below should be displayed :

Our Java application

Now that our database, schema and data are all set, we can jump to our Java application.
This will be a basic application that will connect to the database using JDBC, and run a select query on players table and display the result.

Let's start by creating simple project using Maven :

mvn archetype:generate -DgroupId=com.players.app -DartifactId=players-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

This command will create a simple Java project with an App.java class. The first thing we need to do is to modify our pom.xml by adding the jdbc driver for MySQL database as a dependency and the build plugins to generate a Jar file.

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.22</version>
</dependency>

<build>
  <plugins>
    <plugin>
      <artifactId>maven-assembly-plugin</artifactId>
        <configuration>
      <archive>
        <manifest>
          <mainClass>com.players.app.App</mainClass>
        </manifest>
          </archive>
          <descriptorRefs>
            <descriptorRef>jar-with dependencies</descriptorRef>
          </descriptorRefs>
    </configuration>
    </plugin>
    <plugin>
    <!-- Build an executable JAR -->
      <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
      <version>3.1.0</version>
        <configuration>
          <archive>
            <manifest>                   
                  <addClasspath>true</addClasspath>              
                    <classpathPrefix>lib/</classpathPrefix>                          
                      <mainClass>com.players.app.App
                        </mainClass>
        </manifest>
          </archive>
        </configuration>
      </plugin>
    </plugins>
</build>

Now, we can write some Java code, our application is a silly application which will connect to the playersdb database (we ran on a container previously), execute an sql query and display the result,
This is the code of our Java class, you will find the github url at the end of this post.

public class App {
    // in the dbhost the first playersdb is the container name and the second one is the database name
    private static String connString = "jdbc:mysql://playersdb:3306/playersdb";
    private static String username = "juser";
    private static String password = "password";
    private static Connection conn;
    private static String sql_req = "select * from players";
    private static Statement stmt;
    private static ResultSet results;

    public static void main(String[] args) {

        try {
            conn = DriverManager.getConnection(dbhost, username, password);
            System.out.println("Connecting...");
            System.out.println("Connected !!");

            stmt = conn.createStatement();
            results = stmt.executeQuery(sql_req);

            while (results.next()) {
                System.out.println("Id = " + results.getInt("id") + "\n" + "FirstName = "
                        + results.getString("firstname") + "\n" + "LastName = " + results.getString("lastname") + "\n"
                        + "Team = " + results.getString("team") + "Position = " + results.getString("position"));

            }
        } catch (SQLException e) {
            System.out.println("Cannot connect to database connection");
            e.printStackTrace();
        }
    }
}

Tip : we can test our java application locally, to do this all we need to do is run the mysql container with a port mapping option -p 3306:3306, and replace the host name in connection string by localhost or 127.0.0.1, which will give us jdbc:mysql://localhost:3306/playersdb

Once this is done, we can run maven to generate the Jar file, to do this you can run maven from your IDE (Eclipse, IntelliJ, VScode...) or you can simply open your terminal (CMD in windows, terminal in linux...) go to the project folder and run :
mvn assembly:single
This will build the project and will create a Jar file in the target folder. This is what you should see after the build finish:

You can see that a Jar file with the name players-app-1.0-jar-with-dependencies.jar has been created.

Our java application containerization with Docker

At this point, we have our MySQL container ready, we have our jar file as well, all we need now, is a container in which our jar will be executed. For this let's create a new folder, copy in it the Jar file we created above, for simplification let's rename it players.jar. In the same folder let create a file called dockerfile, this file will contains the instructions to create a Docker image with our specific needs, in this case, an image that contains our jar file which will be executed every time we run the container from this image.
Let's open our dockerfile with a text editor and paste into it those instructions :

FROM openjdk:11

COPY /players.jar /players.jar

CMD ["java", "-jar", "/players.jar"]

So what those instructions means ? the FROM instruction set the base image, a valid Docker file must start with a FROM.
Then COPY will copy our jar file into the image.
And finally CMD, this instruction will provides defaults for an executing container, in our case, every time we run the container the command java -jar players.jar will be executed, this command we usually use to execute a jar file.

Once our dokcerfile created, we can create our image by executing this command :
docker build -t playersapp:1.0 .
This command will build our image file from the dockerfile.

Now we can see that our image playersapp with the tag 1.0 is available, to check this we need to run docker images :

We are almost there !! Now, all will need to do is to run a container from our image playersapp:1.0, this container need to be in the same network than our MySQL container, so let's run this command :
docker run --name playersapp --network mynet playersapp:1.0
And now we can see the list of the players we created before in this post :

Conclusion

We have reached the end of this tutorial, although the application is very simple, the objective here is have an idea about what cloud-native is, and a step-by-step to follow to run a java program from a container.

In the next post, our application will evolve into a spring boot application, and we will use docker compose. So see you soon ✌️

GitHub repo of the players app : players-app
If you want to learn more a about cloud native :
- This book : cloud-native-patterns
- Microsoft docs Introduction to cloud-native
To learn Docker, the official doc is very good : docker docs