How to Deploy Mancala With Minikube - A Beginner's guide

1. Introduction According to Ultraboard Games, the mancala game has existed for about 7000 years. This means that since the middle neolithic phase of History, mankind has been playing this game. The first time I came across this game was when my grandmother had a game that she would call The Stones Game. Later in life, when I came across some colleagues who invited me to play board games at ISEL, I realized that this “Stones game” was actually called Mancala. Back in the day, I made a version of this game in C. Unfortunately that version is long gone. Too much time has passed and at the speed technology goes, I became more interested in other languages like Scala, Kotlin, and, of course, Java. 💻Since 2005, I could never find that game again. Back in 2015, I got the motivation to create Mancala again using Java, OOP design patterns, application of ACID principles, and all the rules invented by Robert Martin (a.k.a. Uncle Bob) to create a Clean Code. These are also many times referred to as SOLID principles. This motivation came out because I was looking for an opportunity to work on an amazing project with different technologies. In the end, I met some amazing colleagues from Eastern Europe who during coffee brought that Mancala subject up. I took a deep dive through the memory lane during my university years and I thought, “Why don’t I just make Mancala all over again?” It turns out that a little time later, I had the first version of “The Stones Game” complete and MancalaJE was a reality. 🎉In this article, we are going to set up a deployment environment using minikube. To be very direct, minikube basically generates a virtual machine that contains all the Kubernetes setup. With minikube, we can spawn a complete virtualization and get it up and running with all our services. Just like Kubernetes, we can create services, load balancers, deployments, pods, and containers. Minkube is more limited, and you can look at it from a simple perspective. It’s basically Kubernetes with more limitations, which for testing, can really make a difference and leverage the complete pipeline setup. 🙌 2. Requirements For this article, we are expected to know what a container, an image, docker and virtualization are. We are also expected to work on a machine with virtualization capabilities. If you are using your work computer, chances are, that what you are working on, isn’t really an operating system. Instead, you might be working on a virtual machine image without even knowing it. If that is the case, just work your 8 hours a day and try the lessons of this article at home with your mega personal machine. A Mac Pro is all the rage at current times, but any machine with at least 16Gb, 8 core, and 250Gb disk space will do. You can also run it with something less, but you might face difficulties. Dual cores can be really painful when running virtualization environments. Further, we need virtualization software which can be Virtual Box or VMWare. It’s entirely up to you. Just remember that in order to be successful with this article, you’ll need to have a complete installation. Trial versions will probably be difficult to work with. For details about VMWare, please have a look at the projects repo. For purposes of simplicity, we will be using Virtual Box in this article only. 3. Implementation Design in a Nutshell In this article, we only need to understand a few basic things about the implementation. The only thing we have here is a front-end service, a back-end service, and a database service. These three could work together in a single container, but that’s not what we want. We are interested in setting them up in different environments and somehow enabling them to communicate with each other. For this, we have minikube. Minikube will start kubernetes and make it run on a virtual machine. For a basic understanding of what we are going to build and to get a picture of it, let’s have a look at the following diagram: This is just a main overview of what we want to achieve. At this point, our interest is just to simplify as best as possible the actual implementation of the game. What’s important is that we have to guarantee the interactions between the client, the front-end, the back-end and the database. Now, let’s have a look at the Kubernetes dashboard and see what we are going to try to achieve: What we are looking at is three pods that have been created. Let’s keep this in mind. We are going to get pods running. For now, we are just going to go briefly through a couple of important aspects of Kubernetes in general and greatly simplify what they are.: Pods — pod is a collection of running containers ReplicaSet — replica set is a set of identical pods running at the same time Deployments — deployment provides declarative updates for Pods and Replica sets Services — n abstract way to expose an application running on a set of Pods as a network service. Cluster — unit which contains all separate running elements described above. We are going to dive into these four concepts and see if we can make a successful deployment using basic Kubernetes syntax with minikube. Here is a good visualization of what we are going to achieve: 4. Configuration Let’s first check out the project from GitHub. Now, let’s go to the root folder. What we are going to do here is to create our minikube. 4.1. Starting minikube First, we configure our VM driver to use a virtual box: minikube config set vm-driver virtualbox Then, we build our minikube virtual machine and mention that we want to use another range of ports. This is important because we want to use port 80 as our exchange port for our cluster: minikube start — vm-driver=virtualbox — extra-config=apiserver.service-node-port-range=1–30000 This should be the result: 😄 minikube v1.7.3 on Darwin 10.15.3 ✨ Using the virtualbox driver based on user configuration ⌛ Reconfiguring existing host … 🏃 Using the running virtualbox “minikube” VM … 🐳 Preparing Kubernetes v1.17.3 on Docker 19.03.6 … ▪ apiserver.service-node-port-range=1–30000 🚀 Launching Kubernetes … 🌟 Enabling addons: dashboard, default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use “minikube” Now let’s make kubectl understand that it’s working with minikube: kubectl config use-context minikube Once we are done with this, we should now be able to create our images. In order to do this, we create our images inside the newly created virtual machine. That virtual machine is called minikube and we can see that perfectly if we go to the virtual box and check the virtual machine statuses: We have now finalized our main setup for minikube. We have accomplished the creation of a minikube. Now, let’s get our images ready and make sure they are available for deployment. 4.2. Creating the Images At this moment, we know that we need to create 3 images. In our repo, we have named these as the following: mancalaje-postgresql — This is the image that runs the database. mancalaje — This is our back end service which serves the business logic. mancalaje-fe — This is the image that runs the front end code. Let’s check the details of our docker files. 4.2.1. Mancala JE Postgresql We can find this docker file in docker-psql/Dockerfile:FROM library/postgres:12. This is a very simple docker file, which basically creates a new image from an already existing image library/postgrs:12. Since our new image is empty, we don’t strictly need to do this. This is just to make this tutorial simple and to keep the focus on what we are trying to achieve.In the same folder we can find the .env file: POSTGRES_USER=postgres POSTGRES_PASSWORD=admin POSTGRES_DB=mancalajedb Using this environment file, we can easily start a container using our newly created image with a username/password of postgres/admin and database of mancalajedb. 4.2.2. Mancala JE We can find this docker file in mancalaje-service/Dockerfile: FROM jesperancinha/je-all-build:0.0.1 ENV runningFolder /usr/local/bin/ WORKDIR ${runningFolder} RUN apt-get update RUN [“/bin/bash”, “-c”, “debconf-set-selections <<< \”postfix postfix/mailname string test\””] RUN [“/bin/bash”, “-c”, “debconf-set-selections <<< \”postfix postfix/main_mailer_type string ‘No configuration’\””] RUN apt-get install -y — assume-yes postfix RUN touch /etc/postfix/main.cf COPY target/mancalaje-service*.jar ${runningFolder} COPY entrypoint.sh ${runningFolder} ENTRYPOINT [“entrypoint.sh”] This image is created as an addition to one of my preset created images called jesperancinha/je-all-build:0.0.1. It’s only important to note that in this image I’m just making sure of three important things: Postfix installation. The placement of the running Spring Boot jar file. The call to the ENTRYPOINT. This is the script that will start once the container is running. Let’s have a look at the startup entrypoint script: #!/usr/bin/env bash postfix start java -jar -Dspring.profiles.active=prod mancalaje-service-1.1.1-SNAPSHOT.jar Here, we are starting postfix and starting the application. Notice that the profile is prod. Since the profile is prod, and this is a Spring Boot application, let’s further take some time to analyze the application-prod.yml of our application: spring: session: jdbc: table-name: spring_session initialize-schema: always store-type: jdbc jpa: properties: hibernate: dialect: org.hibernate.dialect.PostgreSQL9Dialect jdbc: lob: non_contextual_creation: true hibernate: ddl-auto: update datasource: driver-class-name: org.postgresql.Driver url: jdbc:postgresql://mancalaje-postgresql:5432/mancalajedb username: postgres password: admin As we can see, we have configured our application to run against a database server named mancalaje-postgresql. This is very important to keep in mind because this is where we begin to see our first indication that we are working in a virtual environment. We will see further on, how will this work in minikube with Kubernetes. 4.2.3. Mancala JE Front End We finally reached the creation of the front end image. The docker file to this image is located in mancalaje-fe/docker-files/Dockerfile: FROM jesperancinha/je-all-build:0.0.1 ENV runningFolder /usr/local/bin/ WORKDIR ${runningFolder} RUN apt-get update COPY default.conf /etc/nginx/conf.d/default.conf COPY nginx.conf /etc/nginx/nginx.conf COPY build /usr/share/nginx/html CMD nginx -t && nginx && tail -f /dev/null In this docker file, we are just making sure that our NGINX is properly configured and that our build done with react-scripts build will be copied to the deployment location. Let’s have a quick look at the NGINX setup. First, let’s look at the main nginx.conf file. It is located in the same folder: user root; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; add_header 'Referrer-Policy' 'unsafe-url'; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; } Essentially, this is just the default configuration file that comes with NGINX. However, let’s zoom in on the last line: include /etc/nginx/conf.d/*.conf;. Here, we are specifying where we want our subdomains to be configured. For our case, we only need the default.conf file: server { listen 80; listen [::]:80; root /usr/share/nginx/html; server_name _; location /api/ { proxy_pass http://mancalaje:8087/api/; } } It’s important to understand this file in order to realize how we connect the front end to the back end. Let’s look at the line where we see: http://mancalaje:8087/api/;. This is where we proxy all our calls to our API to the back end. Our back-end service will then run on a virtualized container under the name of mancalaje. Finally, it is important to notice the last line of this image creation file: CMD nginx -t && nginx && tail -f /dev/null. An important lesson is to be taken with the use of this command. CMD is the first command executed after image creation. The reason why none of its commands has been placed during image creation is because the start of NGINX will read the configuration files and try to find where the server mancalaje is. At this point, NGINX won’t be able, of course, to find server mancalaje. Let’s continue and we’ll see how this will work. 4.2.4. Setting it all up At this stage, we have created all of our necessary configuration and Docker files. Let’s create the images. We need first to login to minikube and then create our images inside. This is the command list we need to follow: minikube ssh cd /mancalaje/docker-psql docker build — file=Dockerfile — tag=mancalaje-postgresql:latest — rm=true . cd /mancalaje/mancalaje-service docker build — file=Dockerfile — tag=mancalaje:latest — rm=true . cd /mancalaje/mancalaje-fe/docker-files docker build — file=Dockerfile — tag=mancalaje-fe:latest — rm=true . Once we are done with all of these commands, we should be able to see a list of all images: docker images This is the output: REPOSITORY TAG IMAGE ID CREATED SIZE mancalaje-fe latest 4d2ba941a166 19 hours ago 1.24GB mancalaje latest 65f681e03990 20 hours ago 1.33GB mancalaje-postgresql latest 73119b8892f9 4 days ago 314MB At this point, we are ready to start creating our pods, services, replication sets, load balancers, and whatever suits our needs in a Kubernetes fashion. 4.3. Creating the Deployments 4.3.1. Mancala JE Postgresql Let’s start by looking at the deployment declaration located in the deployment file. For this case, it is located at docker-psql/postgres-deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje-postgresql spec: selector: matchLabels: app: mancalaje-postgresql tier: backend replicas: 1 template: metadata: labels: app: mancalaje-postgresql tier: backend spec: containers: - name: mancalaje-postgresql image: mancalaje-postgresql:latest env: - name: POSTGRES_USER value: "postgres" - name: POSTGRES_PASSWORD value: "admin" - name: POSTGRES_DB value: "mancalajedb" imagePullPolicy: Never ports: - containerPort: 5432 Let’s analyze this file quickly. First, let’s just realize that for such a simple application, the naming of things like metadata and app, don’t really matter and aren’t relevant to our deployment. However, our container name is. This is the name used to identify and make connections through the network. Notice also that I have placed the Postgres configuration parameters in the yaml file itself. For this article, it’s best to keep everything in the same file to further understand this file. Kubernetes files have a parameter called kind. This is how we define what sort of action we are configuring. In this case, we are configuring Deployment. We can also see the property replicas. In our example, we are only going to use replicas of one instance. We are also allowing our containerPort to be available on port 5432. 4.3.2. Mancala JE For the Spring Boot service, the deployment file is located at: mancalaje-service/mancalaje-deployment.yaml. This is the configuration: apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje spec: selector: matchLabels: app: mancalaje tier: backend replicas: 1 template: metadata: labels: app: mancalaje tier: backend spec: containers: - name: mancalaje image: mancalaje:latest imagePullPolicy: Never ports: - containerPort: 8087 It’s important to notice that port 8087 is being exposed. Since we didn’t specify this in the Dockerfile, we need to specify that this port will be opened and used within our network. 4.3.3. Mancala JE Front End We finally reached our final deployment file. This is our front end deployment file. It is located in mancalaje-fe/mancalaje-fe-deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje-fe spec: selector: matchLabels: app: mancalaje-fe tier: frontend track: stable replicas: 1 template: metadata: labels: app: mancalaje-fe tier: frontend track: stable spec: containers: - name: mancalaje-fe image: mancalaje-fe:latest imagePullPolicy: Never ports: - name: http containerPort: 80 We can clearly see that this deployment file doesn’t differ that much from the previous one. In fact, the only functional difference is just the fact that it is using port 80 to expose the container. 4.4. Creating the Services Before looking at our different services setup, let’s think about how we want to start our services up. We have a database that we need in order to save user data, to save the game state and in general keep user-logged data and user-logged-off data. We are 100% sure we do not want to expose a running container with our database in it. We are now pretty much sure that we want to keep this database isolated from the outside. In the same way, we only want users to perform authenticated operations. Although the services should be available to the outside, it’s pretty easy to realize that we want some control over how requests are made and who accesses the REST methods. We need to allow some access to them, but let’s just say that this will happen via a proxy. In this way we are still keeping our backend isolated from the outside. In this case, we know that a running container with our application in it, it’s also supposed to be isolated. Finally, we know that interactions with our applications happen via the user and what the user does in the front end. If anything should be open to the outside is our container running the front end. This is what the Front end is supposed to do. Once authenticated, our user can interact with the Front End and play the game, create a new game, register, re-register, win a game, lose a game, etc. What the user still won’t (or shouldn’t :)) be able to do is hack into the system. Note that systems can always be hacked. All we can do is take measures to make it more difficult. 4.4.1. Mancala JE Postgresql Let’s have a look at the service declaration for our database image in the deployment file found in docker-psql/postgres-deployment.yaml. kind: Service apiVersion: v1 metadata: name: mancalaje-postgresql spec: selector: app: mancalaje-postgresql tier: backend ports: - protocol: TCP port: 5432 type: ClusterIP All of the fields are pretty self-explanatory. The one where we should give more attention is the field type. As mentioned before, this is where we define the type of service we want to run. As we mentioned, in the introduction to this segment, we want our database service to run isolated. That is what type ClusterIP is for. It means that our service will be available within the cluster and from the outside, we won’t be able to reach it. We have exposed our port, but haven’t really used it. To do that we define a port in the ports field to have value 5432. 4.4.2. Mancala JE Let’s now see how we have our main Spring Boot service configured. It’s configured in the deployment file located at: mancalaje-service/mancalaje-deployment.yaml: kind: Service apiVersion: v1 metadata: name: mancalaje spec: selector: app: mancalaje tier: backend ports: - protocol: TCP port: 8087 type: ClusterIP The configuration is the same. The only difference is the used port. In this case, it is 8087. For the same reasons, it is of type ClusterIP. 4.4.3. Mancala JE Front End Finally, let’s look at the services Front End. This one can be found in the deployment file located at mancalaje-fe/mancalaje-fe-deployment.yaml: kind: Service apiVersion: v1 metadata: name: mancalaje-fe spec: type: NodePort selector: app: mancalaje-fe tier: frontend ports: - name: http port: 80 targetPort: 80 protocol: TCP nodePort: 80 There are some differences to this declaration. The Front End service needs to be in some way open to the outside world. We have already declared previously in our NGINX configuration how that proxy should work. To make this possible we are using in this example NodePort. This will expose different ports to our needs. We have 3 different port configurations. To access our service we need nodePort to be 80. To get this port to be available in the cluster we say that port is 80. Inside our cluster, we are also mapping to targetPort 80. This is the reason why we need to configure so many 80’s. It has only to do with the fact that they serve different purposes. 5. Firing up the environment We finally reached the fun part of this setup. To test our environment at this stage, let’s just try a few commands. Let’s first look at the kubeclt get nodes command: kubeclt get nodes This is the result: NAME STATUS ROLES AGE VERSION minikube Ready master 4m4s v1.17.3 The result of this command lets us know that our node is named as minikube and that it is ready. In later articles, I will take a deep dive into the usage of ROLES. Wa have the age of our node which in this case is approximately 4 minutes.Let’s try kubectl get pods. We should be getting this as a return message: No resources found in default namespace. This is logic because we haven’t created anything yet. Let’s do that now. Let’s start by effectively creating the deployments with our deployment setup in our deployment files. In the root folder let’s run these commands: kubectl create -f docker-psql/postgres-deployment.yaml kubectl create -f mancalaje-service/mancalaje-deployment.yaml kubectl create -f mancalaje-fe/mancalaje-fe-deployment.yaml These three commands will use the images created in minikube to fire up deployments and services. Let’s run the kubectl get pods again: kubectl get pods These are the logs: NAME READY STATUS RESTARTS AGE mancalaje-5ffdbf7ddf-5mj8l 1/1 Running 0 7s mancalaje-fe-6455c45cfb-twrv2 1/1 Running 0 4s mancalaje-postgresql-7f85dd455-kc4kk 1/1 Running 0 7s We now realize that our pods are running. Let’s have a look if we have deployments ready and the matching services. First, let's see our deployments. Let’s run kubectl get deployments: kubectl get deployments And this is the result: NAME READY UP-TO-DATE AVAILABLE AGE mancalaje 1/1 1 1 3m20s mancalaje-fe 1/1 1 1 3m17s mancalaje-postgresql 1/1 1 1 3m20s So indeed. We have three deployments ready. Let’s see if our create command has also created services. This can be achieved by running command kubectl get services: kubectl get services And we should see something like this in the console NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 12m mancalaje ClusterIP 10.100.182.171 8087/TCP 4m38s mancalaje-fe NodePort 10.107.130.151 80:80/TCP 4m35s mancalaje-postgresql ClusterIP 10.107.82.239 5432/TCP 4m38s Great 👍! We’ve got our services running. However, we cannot access them, because they have not been exposed yet. All we need to achieve that is to run the command minikube service mancalaje-fe. minikube service mancalaje-fe In the console, we should see a table like this one: NAMESPACE NAME TARGET PORT TYPE URL default mancalaje-fe http type http://192.168.99.118:80 And this at the end: 🎉 Opening service default/mancalaje-fe in default browser… This command exposes the only service we want to expose outside the cluster. And that service is our front end service. As we can see, there are quite a few steps in getting a service to be exposed outside the cluster. Finally, we will see the opening screen of my MancalaJE game: We did it! We just launched a complete minikube environment in a virtual machine using Virtual box! Let’s just try to create a user. I will create myself. If we click REGISTER, we should see the following screen: I have already filled in the details for my test. The fireproof for this test is that we must be able to register a user. If we can do that, then it means that we have reached the database, registered a user and gone back to the initial screen with a positive 😊message. We should see this now: If my calculations are correct there should be no email sent through the wire. We will discuss this in later articles. Great! We did it. Launch successful! 🚀! 6. Dashboard. For the final chapter of this article, let’s have a look at the dashboards. Minikube comes packed with a dashboard visualization mode. To see it, let’s run minikube dashboard: minikube dashboard 🔌 Enabling dashboard … 🤔 Verifying dashboard health … 🚀 Launching proxy … 🤔 Verifying proxy health … 🎉 Opening http://127.0.0.1:57913/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser… This is the main dashboard page. Here we can monitor the secrets, the node, the services, the replica sets, the pods, and finally the deployments. This concludes our session about the basic functionalities of minikube applied to my mancala version: MancalaJE. 7. Cheat sheet Let’s see if we can remember how to use all the commands. I’ve placed them all here. The idea is to enjoy running them at the root directory of the project and check results ▶️: minikube delete # Just in case 😉 minikube config set vm-driver virtualbox minikube start - vm-driver=virtualbox - extra-config=apiserver.service-node-port-range=1–30000 kubectl config use-context minikube minikube mount .:/mancalaje minikube ssh cd /mancalaje/docker-psql docker build - file=Dockerfile - tag=mancalaje-postgresql:latest - rm=true . cd /mancalaje/mancalaje-service docker build - file=Dockerfile - tag=mancalaje:latest - rm=true . cd /mancalaje/mancalaje-fe/docker-files docker build - file=Dockerfile - tag=mancalaje-fe:latest - rm=true . exit kubectl create -f docker-psql/postgres-deployment.yaml kubectl create -f mancalaje-service/mancalaje-deployment.yaml kubectl create -f mancalaje-fe/mancalaje-fe-deployment.yaml kubectl delete service mancalaje-postgresql kubectl delete deployment mancalaje-postgresql kubectl delete service mancalaje kubectl delete deployment mancalaje kubectl delete service mancalaje-fe kubectl delete deployment mancalaje-fe minikube service mancalaje-postgresql minikube service mancalaje minikube service mancalaje-f kubectl get deployments kubectl get services kubectl get pods kubectl get nodes 8. Conclusion In this article, we have seen how to fire up a minikube application which depends on a typical MVC setup. We have a database, a service, and a front end. This application has been fully developed with Spring Boot, ReactJS, and PostgreSQL.I hope that with this setup I was able to explain how I was able to set up my own Minikube environment in my machine and with that to have given guidance on how to set this up. Minikube isn’t difficult to setup and that is precisely where its potential lies. With minikube we can perform a lot of useful operations:* Images are created in an isolated form. If we remove our VM(Virtual Machine), we remove everything at once.* It’s a nice and compact way of visualizing our environment and making tests* We can always make different configurations. Minikube runs a single node though. In case we want more nodes we are probably better off going full K8s. With this article, we still haven’t seen in practice how the different types of configuration can help us. After exercising and going through this article we can just remove everything with one simple command: $ minikube delete And it’s gone… 🗑. All images, containers, pods… all gone! 👍I have placed all the source code of this application in GitHub hope that you have enjoyed this article as much as I enjoyed writing it. Thanks in advance for your help, and thank you for reading! 9. References OpenShift by Tutorials Point Learn Open Shift Minishift Minishif Installation Fabric 8 maven plugin Fabric 8 What is minikube, kubectl and kubelet by Andreth Salazar Install Minikube Installing Kubernetes with Minikube Trigger a Spring Batch job with a JMS message Postman Spring Boot OAuth2 Social Login with Google, Facebook, and Github - Part 1 Shields IO How To Install Oracle Java 8 and OpenJDK 11 on Ubuntu 18.04, 19.04 Build and Deploy a Spring Boot App on Kubernetes (Minikube) Apache MQ BrokerService Apache MQ BrokerFactory Apache MQ ActiveMQConnectionFactory Using Meslo LG with the Windows Console Install iTerm2 with Solarized in 2017 Oh My Zsh will not make you a 10x developer...but you may feel like one Oh My ZSH! How to add Custom Fonts to Command Prompt in Windows 10 How can I add additional fonts to the Windows console? Powerline fonts Microsoft Terminal How To Install Minikube on Ubuntu 18.04 / Debian 10 Linux Install KVM on CentOS / RHEL / Ubuntu / Debian / SLES / Arch Linux choco package? #9 Workstation Player Try VMware Workstation Pro Download VMware VIX 1.15.7 Automation Tools and SDK(s) 1. Introduction According to Ultraboard Games, the mancala game has existed for about 7000 years. This means that since the middle neolithic phase of History, mankind has been playing this game. The first time I came across this game was when my grandmother had a game that she would call The Stones Game. Later in life, when I came across some colleagues who invited me to play board games at ISEL, I realized that this “Stones game” was actually called Mancala. Back in the day, I made a version of this game in C. Unfortunately that version is long gone. Too much time has passed and at the speed technology goes, I became more interested in other languages like Scala, Kotlin, and, of course, Java. 💻Since 2005, I could never find that game again. Back in 2015, I got the motivation to create Mancala again using Java, OOP design patterns, application of ACID principles, and all the rules invented by Robert Martin (a.k.a. Uncle Bob) to create a Clean Code. These are also many times referred to as SOLID principles. This motivation came out because I was looking for an opportunity to work on an amazing project with different technologies. In the end, I met some amazing colleagues from Eastern Europe who during coffee brought that Mancala subject up. I took a deep dive through the memory lane during my university years and I thought, “Why don’t I just make Mancala all over again?” It turns out that a little time later, I had the first version of “The Stones Game” complete and MancalaJE was a reality. 🎉In this article, we are going to set up a deployment environment using minikube. To be very direct, minikube basically generates a virtual machine that contains all the Kubernetes setup. With minikube, we can spawn a complete virtualization and get it up and running with all our services. Just like Kubernetes, we can create services, load balancers, deployments, pods, and containers. Minkube is more limited, and you can look at it from a simple perspective. It’s basically Kubernetes with more limitations, which for testing, can really make a difference and leverage the complete pipeline setup. 🙌 2. Requirements For this article, we are expected to know what a container, an image, docker and virtualization are. We are also expected to work on a machine with virtualization capabilities. If you are using your work computer, chances are, that what you are working on, isn’t really an operating system. Instead, you might be working on a virtual machine image without even knowing it. If that is the case, just work your 8 hours a day and try the lessons of this article at home with your mega personal machine. A Mac Pro is all the rage at current times, but any machine with at least 16Gb, 8 core, and 250Gb disk space will do. You can also run it with something less, but you might face difficulties. Dual cores can be really painful when running virtualization environments. Further, we need virtualization software which can be Virtual Box or VMWare. It’s entirely up to you. Just remember that in order to be successful with this article, you’ll need to have a complete installation. Trial versions will probably be difficult to work with. For details about VMWare, please have a look at the projects repo. For purposes of simplicity, we will be using Virtual Box in this article only. 3. Implementation Design in a Nutshell In this article, we only need to understand a few basic things about the implementation. The only thing we have here is a front-end service, a back-end service, and a database service. These three could work together in a single container, but that’s not what we want. We are interested in setting them up in different environments and somehow enabling them to communicate with each other. For this, we have minikube. Minikube will start kubernetes and make it run on a virtual machine. For a basic understanding of what we are going to build and to get a picture of it, let’s have a look at the following diagram: This is just a main overview of what we want to achieve. At this point, our interest is just to simplify as best as possible the actual implementation of the game. What’s important is that we have to guarantee the interactions between the client, the front-end, the back-end and the database. Now, let’s have a look at the Kubernetes dashboard and see what we are going to try to achieve: What we are looking at is three pods that have been created. Let’s keep this in mind. We are going to get pods running. For now, we are just going to go briefly through a couple of important aspects of Kubernetes in general and greatly simplify what they are.: Pods — pod is a collection of running containers ReplicaSet — replica set is a set of identical pods running at the same time Deployments — deployment provides declarative updates for Pods and Replica sets Services — n abstract way to expose an application running on a set of Pods as a network service. Cluster — unit which contains all separate running elements described above. We are going to dive into these four concepts and see if we can make a successful deployment using basic Kubernetes syntax with minikube. Here is a good visualization of what we are going to achieve: Pods — pod is a collection of running containers ReplicaSet — replica set is a set of identical pods running at the same time Deployments — deployment provides declarative updates for Pods and Replica sets Services — n abstract way to expose an application running on a set of Pods as a network service. Cluster — unit which contains all separate running elements described above. We are going to dive into these four concepts and see if we can make a successful deployment using basic Kubernetes syntax with minikube. Here is a good visualization of what we are going to achieve: 4. Configuration Let’s first check out the project from GitHub. Now, let’s go to the root folder. What we are going to do here is to create our minikube. 4.1. Starting minikube First, we configure our VM driver to use a virtual box: minikube config set vm-driver virtualbox minikube config set vm-driver virtualbox Then, we build our minikube virtual machine and mention that we want to use another range of ports. This is important because we want to use port 80 as our exchange port for our cluster: minikube start — vm-driver=virtualbox — extra-config=apiserver.service-node-port-range=1–30000 minikube start — vm-driver=virtualbox — extra-config=apiserver.service-node-port-range=1–30000 This should be the result: 😄 minikube v1.7.3 on Darwin 10.15.3 ✨ Using the virtualbox driver based on user configuration ⌛ Reconfiguring existing host … 🏃 Using the running virtualbox “minikube” VM … 🐳 Preparing Kubernetes v1.17.3 on Docker 19.03.6 … ▪ apiserver.service-node-port-range=1–30000 🚀 Launching Kubernetes … 🌟 Enabling addons: dashboard, default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use “minikube” Now let’s make kubectl understand that it’s working with minikube: kubectl config use-context minikube 😄 minikube v1.7.3 on Darwin 10.15.3 ✨ Using the virtualbox driver based on user configuration ⌛ Reconfiguring existing host … 🏃 Using the running virtualbox “minikube” VM … 🐳 Preparing Kubernetes v1.17.3 on Docker 19.03.6 … ▪ apiserver.service-node-port-range=1–30000 🚀 Launching Kubernetes … 🌟 Enabling addons: dashboard, default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use “minikube” Now let’s make kubectl understand that it’s working with minikube: kubectl config use-context minikube Once we are done with this, we should now be able to create our images. In order to do this, we create our images inside the newly created virtual machine. That virtual machine is called minikube and we can see that perfectly if we go to the virtual box and check the virtual machine statuses: We have now finalized our main setup for minikube. We have accomplished the creation of a minikube. Now, let’s get our images ready and make sure they are available for deployment. 4.2. Creating the Images At this moment, we know that we need to create 3 images. In our repo, we have named these as the following: mancalaje-postgresql — This is the image that runs the database. mancalaje — This is our back end service which serves the business logic. mancalaje-fe — This is the image that runs the front end code. mancalaje-postgresql — This is the image that runs the database. mancalaje — This is our back end service which serves the business logic. mancalaje-fe — This is the image that runs the front end code. Let’s check the details of our docker files. 4.2.1. Mancala JE Postgresql We can find this docker file in docker-psql/Dockerfile:FROM library/postgres:12. This is a very simple docker file, which basically creates a new image from an already existing image library/postgrs:12. Since our new image is empty, we don’t strictly need to do this. This is just to make this tutorial simple and to keep the focus on what we are trying to achieve.In the same folder we can find the .env file: POSTGRES_USER=postgres POSTGRES_PASSWORD=admin POSTGRES_DB=mancalajedb POSTGRES_USER=postgres POSTGRES_PASSWORD=admin POSTGRES_DB=mancalajedb Using this environment file, we can easily start a container using our newly created image with a username/password of postgres/admin and database of mancalajedb. 4.2.2. Mancala JE We can find this docker file in mancalaje-service/Dockerfile: FROM jesperancinha/je-all-build:0.0.1 ENV runningFolder /usr/local/bin/ WORKDIR ${runningFolder} RUN apt-get update RUN [“/bin/bash”, “-c”, “debconf-set-selections <<< \”postfix postfix/mailname string test\””] RUN [“/bin/bash”, “-c”, “debconf-set-selections <<< \”postfix postfix/main_mailer_type string ‘No configuration’\””] RUN apt-get install -y — assume-yes postfix RUN touch /etc/postfix/main.cf COPY target/mancalaje-service*.jar ${runningFolder} COPY entrypoint.sh ${runningFolder} ENTRYPOINT [“entrypoint.sh”] FROM jesperancinha/je-all-build:0.0.1 ENV runningFolder /usr/local/bin/ WORKDIR ${runningFolder} RUN apt-get update RUN [“/bin/bash”, “-c”, “debconf-set-selections <<< \”postfix postfix/mailname string test\””] RUN [“/bin/bash”, “-c”, “debconf-set-selections <<< \”postfix postfix/main_mailer_type string ‘No configuration’\””] RUN apt-get install -y — assume-yes postfix RUN touch /etc/postfix/main.cf COPY target/mancalaje-service*.jar ${runningFolder} COPY entrypoint.sh ${runningFolder} ENTRYPOINT [“entrypoint.sh”] This image is created as an addition to one of my preset created images called jesperancinha/je-all-build:0.0.1. It’s only important to note that in this image I’m just making sure of three important things: Postfix installation. The placement of the running Spring Boot jar file. The call to the ENTRYPOINT. This is the script that will start once the container is running. Postfix installation. The placement of the running Spring Boot jar file. The call to the ENTRYPOINT. This is the script that will start once the container is running. Let’s have a look at the startup entrypoint script: #!/usr/bin/env bash postfix start java -jar -Dspring.profiles.active=prod mancalaje-service-1.1.1-SNAPSHOT.jar #!/usr/bin/env bash postfix start java -jar -Dspring.profiles.active=prod mancalaje-service-1.1.1-SNAPSHOT.jar Here, we are starting postfix and starting the application. Notice that the profile is prod. Since the profile is prod, and this is a Spring Boot application, let’s further take some time to analyze the application-prod.yml of our application: spring: session: jdbc: table-name: spring_session initialize-schema: always store-type: jdbc jpa: properties: hibernate: dialect: org.hibernate.dialect.PostgreSQL9Dialect jdbc: lob: non_contextual_creation: true hibernate: ddl-auto: update datasource: driver-class-name: org.postgresql.Driver url: jdbc:postgresql://mancalaje-postgresql:5432/mancalajedb username: postgres password: admin spring: session: jdbc: table-name: spring_session initialize-schema: always store-type: jdbc jpa: properties: hibernate: dialect: org.hibernate.dialect.PostgreSQL9Dialect jdbc: lob: non_contextual_creation: true hibernate: ddl-auto: update datasource: driver-class-name: org.postgresql.Driver url: jdbc:postgresql://mancalaje-postgresql:5432/mancalajedb username: postgres password: admin As we can see, we have configured our application to run against a database server named mancalaje-postgresql. This is very important to keep in mind because this is where we begin to see our first indication that we are working in a virtual environment. We will see further on, how will this work in minikube with Kubernetes. 4.2.3. Mancala JE Front End We finally reached the creation of the front end image. The docker file to this image is located in mancalaje-fe/docker-files/Dockerfile: FROM jesperancinha/je-all-build:0.0.1 ENV runningFolder /usr/local/bin/ WORKDIR ${runningFolder} RUN apt-get update COPY default.conf /etc/nginx/conf.d/default.conf COPY nginx.conf /etc/nginx/nginx.conf COPY build /usr/share/nginx/html CMD nginx -t && nginx && tail -f /dev/null FROM jesperancinha/je-all-build:0.0.1 ENV runningFolder /usr/local/bin/ WORKDIR ${runningFolder} RUN apt-get update COPY default.conf /etc/nginx/conf.d/default.conf COPY nginx.conf /etc/nginx/nginx.conf COPY build /usr/share/nginx/html CMD nginx -t && nginx && tail -f /dev/null In this docker file, we are just making sure that our NGINX is properly configured and that our build done with react-scripts build will be copied to the deployment location. Let’s have a quick look at the NGINX setup. First, let’s look at the main nginx.conf file. It is located in the same folder: user root; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; add_header 'Referrer-Policy' 'unsafe-url'; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; } user root; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; add_header 'Referrer-Policy' 'unsafe-url'; sendfile on; #tcp_nopush on; keepalive_timeout 65; #gzip on; include /etc/nginx/conf.d/*.conf; } Essentially, this is just the default configuration file that comes with NGINX. However, let’s zoom in on the last line: include /etc/nginx/conf.d/*.conf;. Here, we are specifying where we want our subdomains to be configured. For our case, we only need the default.conf file: server { listen 80; listen [::]:80; root /usr/share/nginx/html; server_name _; location /api/ { proxy_pass http://mancalaje:8087/api/; } } server { listen 80; listen [::]:80; root /usr/share/nginx/html; server_name _; location /api/ { proxy_pass http://mancalaje:8087/api/; } } It’s important to understand this file in order to realize how we connect the front end to the back end. Let’s look at the line where we see: http://mancalaje:8087/api/ ;. This is where we proxy all our calls to our API to the back end. Our back-end service will then run on a virtualized container under the name of mancalaje. Finally, it is important to notice the last line of this image creation file: CMD nginx -t && nginx && tail -f /dev/null. An important lesson is to be taken with the use of this command. CMD is the first command executed after image creation. http://mancalaje:8087/api/ The reason why none of its commands has been placed during image creation is because the start of NGINX will read the configuration files and try to find where the server mancalaje is. At this point, NGINX won’t be able, of course, to find server mancalaje. Let’s continue and we’ll see how this will work. 4.2.4. Setting it all up At this stage, we have created all of our necessary configuration and Docker files. Let’s create the images. We need first to login to minikube and then create our images inside. This is the command list we need to follow: minikube ssh cd /mancalaje/docker-psql docker build — file=Dockerfile — tag=mancalaje-postgresql:latest — rm=true . cd /mancalaje/mancalaje-service docker build — file=Dockerfile — tag=mancalaje:latest — rm=true . cd /mancalaje/mancalaje-fe/docker-files docker build — file=Dockerfile — tag=mancalaje-fe:latest — rm=true . minikube ssh cd /mancalaje/docker-psql docker build — file=Dockerfile — tag=mancalaje-postgresql:latest — rm=true . cd /mancalaje/mancalaje-service docker build — file=Dockerfile — tag=mancalaje:latest — rm=true . cd /mancalaje/mancalaje-fe/docker-files docker build — file=Dockerfile — tag=mancalaje-fe:latest — rm=true . Once we are done with all of these commands, we should be able to see a list of all images: docker images docker images This is the output: REPOSITORY TAG IMAGE ID CREATED SIZE mancalaje-fe latest 4d2ba941a166 19 hours ago 1.24GB mancalaje latest 65f681e03990 20 hours ago 1.33GB mancalaje-postgresql latest 73119b8892f9 4 days ago 314MB REPOSITORY TAG IMAGE ID CREATED SIZE mancalaje-fe latest 4d2ba941a166 19 hours ago 1.24GB mancalaje latest 65f681e03990 20 hours ago 1.33GB mancalaje-postgresql latest 73119b8892f9 4 days ago 314MB At this point, we are ready to start creating our pods, services, replication sets, load balancers, and whatever suits our needs in a Kubernetes fashion. 4.3. Creating the Deployments 4.3.1. Mancala JE Postgresql Let’s start by looking at the deployment declaration located in the deployment file. For this case, it is located at docker-psql/postgres-deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje-postgresql spec: selector: matchLabels: app: mancalaje-postgresql tier: backend replicas: 1 template: metadata: labels: app: mancalaje-postgresql tier: backend spec: containers: - name: mancalaje-postgresql image: mancalaje-postgresql:latest env: - name: POSTGRES_USER value: "postgres" - name: POSTGRES_PASSWORD value: "admin" - name: POSTGRES_DB value: "mancalajedb" imagePullPolicy: Never ports: - containerPort: 5432 apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje-postgresql spec: selector: matchLabels: app: mancalaje-postgresql tier: backend replicas: 1 template: metadata: labels: app: mancalaje-postgresql tier: backend spec: containers: - name: mancalaje-postgresql image: mancalaje-postgresql:latest env: - name: POSTGRES_USER value: "postgres" - name: POSTGRES_PASSWORD value: "admin" - name: POSTGRES_DB value: "mancalajedb" imagePullPolicy: Never ports: - containerPort: 5432 Let’s analyze this file quickly. First, let’s just realize that for such a simple application, the naming of things like metadata and app, don’t really matter and aren’t relevant to our deployment. However, our container name is. This is the name used to identify and make connections through the network. Notice also that I have placed the Postgres configuration parameters in the yaml file itself. For this article, it’s best to keep everything in the same file to further understand this file. Kubernetes files have a parameter called kind. This is how we define what sort of action we are configuring. In this case, we are configuring Deployment. We can also see the property replicas. In our example, we are only going to use replicas of one instance. We are also allowing our containerPort to be available on port 5432. 4.3.2. Mancala JE For the Spring Boot service, the deployment file is located at: mancalaje-service/mancalaje-deployment.yaml. This is the configuration: apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje spec: selector: matchLabels: app: mancalaje tier: backend replicas: 1 template: metadata: labels: app: mancalaje tier: backend spec: containers: - name: mancalaje image: mancalaje:latest imagePullPolicy: Never ports: - containerPort: 8087 apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje spec: selector: matchLabels: app: mancalaje tier: backend replicas: 1 template: metadata: labels: app: mancalaje tier: backend spec: containers: - name: mancalaje image: mancalaje:latest imagePullPolicy: Never ports: - containerPort: 8087 It’s important to notice that port 8087 is being exposed. Since we didn’t specify this in the Dockerfile, we need to specify that this port will be opened and used within our network. 4.3.3. Mancala JE Front End We finally reached our final deployment file. This is our front end deployment file. It is located in mancalaje-fe/mancalaje-fe-deployment.yaml: apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje-fe spec: selector: matchLabels: app: mancalaje-fe tier: frontend track: stable replicas: 1 template: metadata: labels: app: mancalaje-fe tier: frontend track: stable spec: containers: - name: mancalaje-fe image: mancalaje-fe:latest imagePullPolicy: Never ports: - name: http containerPort: 80 apiVersion: apps/v1 kind: Deployment metadata: name: mancalaje-fe spec: selector: matchLabels: app: mancalaje-fe tier: frontend track: stable replicas: 1 template: metadata: labels: app: mancalaje-fe tier: frontend track: stable spec: containers: - name: mancalaje-fe image: mancalaje-fe:latest imagePullPolicy: Never ports: - name: http containerPort: 80 We can clearly see that this deployment file doesn’t differ that much from the previous one. In fact, the only functional difference is just the fact that it is using port 80 to expose the container. 4.4. Creating the Services Before looking at our different services setup, let’s think about how we want to start our services up. We have a database that we need in order to save user data, to save the game state and in general keep user-logged data and user-logged-off data. We are 100% sure we do not want to expose a running container with our database in it. We are now pretty much sure that we want to keep this database isolated from the outside. In the same way, we only want users to perform authenticated operations. Although the services should be available to the outside, it’s pretty easy to realize that we want some control over how requests are made and who accesses the REST methods. We need to allow some access to them, but let’s just say that this will happen via a proxy. In this way we are still keeping our backend isolated from the outside. In this case, we know that a running container with our application in it, it’s also supposed to be isolated. Finally, we know that interactions with our applications happen via the user and what the user does in the front end. If anything should be open to the outside is our container running the front end. This is what the Front end is supposed to do. Once authenticated, our user can interact with the Front End and play the game, create a new game, register, re-register, win a game, lose a game, etc. What the user still won’t (or shouldn’t :)) be able to do is hack into the system. Note that systems can always be hacked. All we can do is take measures to make it more difficult. 4.4.1. Mancala JE Postgresql Let’s have a look at the service declaration for our database image in the deployment file found in docker-psql/postgres-deployment.yaml. kind: Service apiVersion: v1 metadata: name: mancalaje-postgresql spec: selector: app: mancalaje-postgresql tier: backend ports: - protocol: TCP port: 5432 type: ClusterIP kind: Service apiVersion: v1 metadata: name: mancalaje-postgresql spec: selector: app: mancalaje-postgresql tier: backend ports: - protocol: TCP port: 5432 type: ClusterIP All of the fields are pretty self-explanatory. The one where we should give more attention is the field type. As mentioned before, this is where we define the type of service we want to run. As we mentioned, in the introduction to this segment, we want our database service to run isolated. That is what type ClusterIP is for. It means that our service will be available within the cluster and from the outside, we won’t be able to reach it. We have exposed our port, but haven’t really used it. To do that we define a port in the ports field to have value 5432. 4.4.2. Mancala JE Let’s now see how we have our main Spring Boot service configured. It’s configured in the deployment file located at: mancalaje-service/mancalaje-deployment.yaml: kind: Service apiVersion: v1 metadata: name: mancalaje spec: selector: app: mancalaje tier: backend ports: - protocol: TCP port: 8087 type: ClusterIP kind: Service apiVersion: v1 metadata: name: mancalaje spec: selector: app: mancalaje tier: backend ports: - protocol: TCP port: 8087 type: ClusterIP The configuration is the same. The only difference is the used port. In this case, it is 8087. For the same reasons, it is of type ClusterIP. 4.4.3. Mancala JE Front End Finally, let’s look at the services Front End. This one can be found in the deployment file located at mancalaje-fe/mancalaje-fe-deployment.yaml: kind: Service apiVersion: v1 metadata: name: mancalaje-fe spec: type: NodePort selector: app: mancalaje-fe tier: frontend ports: - name: http port: 80 targetPort: 80 protocol: TCP nodePort: 80 kind: Service apiVersion: v1 metadata: name: mancalaje-fe spec: type: NodePort selector: app: mancalaje-fe tier: frontend ports: - name: http port: 80 targetPort: 80 protocol: TCP nodePort: 80 There are some differences to this declaration. The Front End service needs to be in some way open to the outside world. We have already declared previously in our NGINX configuration how that proxy should work. To make this possible we are using in this example NodePort. This will expose different ports to our needs. We have 3 different port configurations. To access our service we need nodePort to be 80. To get this port to be available in the cluster we say that port is 80. Inside our cluster, we are also mapping to targetPort 80. This is the reason why we need to configure so many 80’s. It has only to do with the fact that they serve different purposes. 5. Firing up the environment We finally reached the fun part of this setup. To test our environment at this stage, let’s just try a few commands. Let’s first look at the kubeclt get nodes command: kubeclt get nodes kubeclt get nodes This is the result: NAME STATUS ROLES AGE VERSION minikube Ready master 4m4s v1.17.3 NAME STATUS ROLES AGE VERSION minikube Ready master 4m4s v1.17.3 The result of this command lets us know that our node is named as minikube and that it is ready. In later articles, I will take a deep dive into the usage of ROLES. Wa have the age of our node which in this case is approximately 4 minutes.Let’s try kubectl get pods. We should be getting this as a return message: No resources found in default namespace. This is logic because we haven’t created anything yet. Let’s do that now. Let’s start by effectively creating the deployments with our deployment setup in our deployment files. In the root folder let’s run these commands: kubectl create -f docker-psql/postgres-deployment.yaml kubectl create -f mancalaje-service/mancalaje-deployment.yaml kubectl create -f mancalaje-fe/mancalaje-fe-deployment.yaml kubectl create -f docker-psql/postgres-deployment.yaml kubectl create -f mancalaje-service/mancalaje-deployment.yaml kubectl create -f mancalaje-fe/mancalaje-fe-deployment.yaml These three commands will use the images created in minikube to fire up deployments and services. Let’s run the kubectl get pods again: kubectl get pods kubectl get pods These are the logs: NAME READY STATUS RESTARTS AGE mancalaje-5ffdbf7ddf-5mj8l 1/1 Running 0 7s mancalaje-fe-6455c45cfb-twrv2 1/1 Running 0 4s mancalaje-postgresql-7f85dd455-kc4kk 1/1 Running 0 7s NAME READY STATUS RESTARTS AGE mancalaje-5ffdbf7ddf-5mj8l 1/1 Running 0 7s mancalaje-fe-6455c45cfb-twrv2 1/1 Running 0 4s mancalaje-postgresql-7f85dd455-kc4kk 1/1 Running 0 7s We now realize that our pods are running. Let’s have a look if we have deployments ready and the matching services. First, let's see our deployments. Let’s run kubectl get deployments: kubectl get deployments kubectl get deployments And this is the result: NAME READY UP-TO-DATE AVAILABLE AGE mancalaje 1/1 1 1 3m20s mancalaje-fe 1/1 1 1 3m17s mancalaje-postgresql 1/1 1 1 3m20s NAME READY UP-TO-DATE AVAILABLE AGE mancalaje 1/1 1 1 3m20s mancalaje-fe 1/1 1 1 3m17s mancalaje-postgresql 1/1 1 1 3m20s So indeed. We have three deployments ready. Let’s see if our create command has also created services. This can be achieved by running command kubectl get services: kubectl get services kubectl get services And we should see something like this in the console NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 12m mancalaje ClusterIP 10.100.182.171 8087/TCP 4m38s mancalaje-fe NodePort 10.107.130.151 80:80/TCP 4m35s mancalaje-postgresql ClusterIP 10.107.82.239 5432/TCP 4m38s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 12m mancalaje ClusterIP 10.100.182.171 8087/TCP 4m38s mancalaje-fe NodePort 10.107.130.151 80:80/TCP 4m35s mancalaje-postgresql ClusterIP 10.107.82.239 5432/TCP 4m38s Great 👍! We’ve got our services running. However, we cannot access them, because they have not been exposed yet. All we need to achieve that is to run the command minikube service mancalaje-fe. minikube service mancalaje-fe minikube service mancalaje-fe In the console, we should see a table like this one: NAMESPACE NAME TARGET PORT TYPE URL default mancalaje-fe http type http://192.168.99.118:80 NAMESPACE NAME TARGET PORT TYPE URL default mancalaje-fe http type http://192.168.99.118:80 NAMESPACE NAME TARGET PORT TYPE URL NAMESPACE NAMESPACE NAME NAME TARGET PORT TYPE TARGET PORT TYPE URL URL default mancalaje-fe http type http://192.168.99.118:80 default default mancalaje-fe mancalaje-fe http type http type http://192.168.99.118:80 http://192.168.99.118:80 http://192.168.99.118:80 http://192.168.99.118:80 And this at the end: 🎉 Opening service default/mancalaje-fe in default browser… 🎉 Opening service default/mancalaje-fe in default browser… This command exposes the only service we want to expose outside the cluster. And that service is our front end service. As we can see, there are quite a few steps in getting a service to be exposed outside the cluster. Finally, we will see the opening screen of my MancalaJE game: We did it! We just launched a complete minikube environment in a virtual machine using Virtual box! Let’s just try to create a user. I will create myself. If we click REGISTER, we should see the following screen: I have already filled in the details for my test. The fireproof for this test is that we must be able to register a user. If we can do that, then it means that we have reached the database, registered a user and gone back to the initial screen with a positive 😊message. We should see this now: If my calculations are correct there should be no email sent through the wire. We will discuss this in later articles. Great! We did it. Launch successful! 🚀! 6. Dashboard. For the final chapter of this article, let’s have a look at the dashboards. Minikube comes packed with a dashboard visualization mode. To see it, let’s run minikube dashboard: minikube dashboard 🔌 Enabling dashboard … 🤔 Verifying dashboard health … 🚀 Launching proxy … 🤔 Verifying proxy health … 🎉 Opening http://127.0.0.1:57913/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser… minikube dashboard 🔌 Enabling dashboard … 🤔 Verifying dashboard health … 🚀 Launching proxy … 🤔 Verifying proxy health … 🎉 Opening http://127.0.0.1:57913/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser… This is the main dashboard page. Here we can monitor the secrets, the node, the services, the replica sets, the pods, and finally the deployments. This concludes our session about the basic functionalities of minikube applied to my mancala version: MancalaJE. 7. Cheat sheet Let’s see if we can remember how to use all the commands. I’ve placed them all here. The idea is to enjoy running them at the root directory of the project and check results ▶️: minikube delete # Just in case 😉 minikube config set vm-driver virtualbox minikube start - vm-driver=virtualbox - extra-config=apiserver.service-node-port-range=1–30000 kubectl config use-context minikube minikube mount .:/mancalaje minikube ssh cd /mancalaje/docker-psql docker build - file=Dockerfile - tag=mancalaje-postgresql:latest - rm=true . cd /mancalaje/mancalaje-service docker build - file=Dockerfile - tag=mancalaje:latest - rm=true . cd /mancalaje/mancalaje-fe/docker-files docker build - file=Dockerfile - tag=mancalaje-fe:latest - rm=true . exit kubectl create -f docker-psql/postgres-deployment.yaml kubectl create -f mancalaje-service/mancalaje-deployment.yaml kubectl create -f mancalaje-fe/mancalaje-fe-deployment.yaml kubectl delete service mancalaje-postgresql kubectl delete deployment mancalaje-postgresql kubectl delete service mancalaje kubectl delete deployment mancalaje kubectl delete service mancalaje-fe kubectl delete deployment mancalaje-fe minikube service mancalaje-postgresql minikube service mancalaje minikube service mancalaje-f kubectl get deployments kubectl get services kubectl get pods kubectl get nodes minikube delete # Just in case 😉 minikube config set vm-driver virtualbox minikube start - vm-driver=virtualbox - extra-config=apiserver.service-node-port-range=1–30000 kubectl config use-context minikube minikube mount .:/mancalaje minikube ssh cd /mancalaje/docker-psql docker build - file=Dockerfile - tag=mancalaje-postgresql:latest - rm=true . cd /mancalaje/mancalaje-service docker build - file=Dockerfile - tag=mancalaje:latest - rm=true . cd /mancalaje/mancalaje-fe/docker-files docker build - file=Dockerfile - tag=mancalaje-fe:latest - rm=true . exit kubectl create -f docker-psql/postgres-deployment.yaml kubectl create -f mancalaje-service/mancalaje-deployment.yaml kubectl create -f mancalaje-fe/mancalaje-fe-deployment.yaml kubectl delete service mancalaje-postgresql kubectl delete deployment mancalaje-postgresql kubectl delete service mancalaje kubectl delete deployment mancalaje kubectl delete service mancalaje-fe kubectl delete deployment mancalaje-fe minikube service mancalaje-postgresql minikube service mancalaje minikube service mancalaje-f kubectl get deployments kubectl get services kubectl get pods kubectl get nodes 8. Conclusion In this article, we have seen how to fire up a minikube application which depends on a typical MVC setup. We have a database, a service, and a front end. This application has been fully developed with Spring Boot, ReactJS, and PostgreSQL.I hope that with this setup I was able to explain how I was able to set up my own Minikube environment in my machine and with that to have given guidance on how to set this up. Minikube isn’t difficult to setup and that is precisely where its potential lies. With minikube we can perform a lot of useful operations:* Images are created in an isolated form. If we remove our VM(Virtual Machine), we remove everything at once.* It’s a nice and compact way of visualizing our environment and making tests* We can always make different configurations. Minikube runs a single node though. In case we want more nodes we are probably better off going full K8s. With this article, we still haven’t seen in practice how the different types of configuration can help us. After exercising and going through this article we can just remove everything with one simple command: $ minikube delete And it’s gone… 🗑. All images, containers, pods… all gone! 👍I have placed all the source code of this application in GitHub hope that you have enjoyed this article as much as I enjoyed writing it. Thanks in advance for your help, and thank you for reading! 9. References OpenShift by Tutorials Point Learn Open Shift Minishift Minishif Installation Fabric 8 maven plugin Fabric 8 What is minikube, kubectl and kubelet by Andreth Salazar Install Minikube Installing Kubernetes with Minikube Trigger a Spring Batch job with a JMS message Postman Spring Boot OAuth2 Social Login with Google, Facebook, and Github - Part 1 Shields IO How To Install Oracle Java 8 and OpenJDK 11 on Ubuntu 18.04, 19.04 Build and Deploy a Spring Boot App on Kubernetes (Minikube) Apache MQ BrokerService Apache MQ BrokerFactory Apache MQ ActiveMQConnectionFactory Using Meslo LG with the Windows Console Install iTerm2 with Solarized in 2017 Oh My Zsh will not make you a 10x developer...but you may feel like one Oh My ZSH! How to add Custom Fonts to Command Prompt in Windows 10 How can I add additional fonts to the Windows console? Powerline fonts Microsoft Terminal How To Install Minikube on Ubuntu 18.04 / Debian 10 Linux Install KVM on CentOS / RHEL / Ubuntu / Debian / SLES / Arch Linux choco package? #9 Workstation Player Try VMware Workstation Pro Download VMware VIX 1.15.7 Automation Tools and SDK(s) OpenShift by Tutorials Point OpenShift by Tutorials Point Learn Open Shift Learn Open Shift Minishift Minishift Minishif Installation Minishif Installation Fabric 8 maven plugin Fabric 8 maven plugin Fabric 8 Fabric 8 What is minikube, kubectl and kubelet by Andreth Salazar What is minikube, kubectl and kubelet by Andreth Salazar Install Minikube Install Minikube Installing Kubernetes with Minikube Installing Kubernetes with Minikube Trigger a Spring Batch job with a JMS message Trigger a Spring Batch job with a JMS message Postman Postman Spring Boot OAuth2 Social Login with Google, Facebook, and Github - Part 1 Spring Boot OAuth2 Social Login with Google, Facebook, and Github - Part 1 Shields IO Shields IO How To Install Oracle Java 8 and OpenJDK 11 on Ubuntu 18.04, 19.04 How To Install Oracle Java 8 and OpenJDK 11 on Ubuntu 18.04, 19.04 Build and Deploy a Spring Boot App on Kubernetes (Minikube) Build and Deploy a Spring Boot App on Kubernetes (Minikube) Apache MQ BrokerService Apache MQ BrokerService Apache MQ BrokerFactory Apache MQ BrokerFactory Apache MQ ActiveMQConnectionFactory Apache MQ ActiveMQConnectionFactory Using Meslo LG with the Windows Console Using Meslo LG with the Windows Console Install iTerm2 with Solarized in 2017 Install iTerm2 with Solarized in 2017 Oh My Zsh will not make you a 10x developer...but you may feel like one Oh My Zsh will not make you a 10x developer...but you may feel like one Oh My ZSH! Oh My ZSH! How to add Custom Fonts to Command Prompt in Windows 10 How to add Custom Fonts to Command Prompt in Windows 10 How can I add additional fonts to the Windows console? How can I add additional fonts to the Windows console? Powerline fonts Powerline fonts Microsoft Terminal Microsoft Terminal How To Install Minikube on Ubuntu 18.04 / Debian 10 Linux How To Install Minikube on Ubuntu 18.04 / Debian 10 Linux Install KVM on CentOS / RHEL / Ubuntu / Debian / SLES / Arch Linux Install KVM on CentOS / RHEL / Ubuntu / Debian / SLES / Arch Linux choco package? #9 choco package? #9 Workstation Player Workstation Player Try VMware Workstation Pro Try VMware Workstation Pro Download VMware VIX 1.15.7 Download VMware VIX 1.15.7 Automation Tools and SDK(s) Automation Tools and SDK(s)