Container-ization of everything else

By : rinormaloku
This entry is part 6 of 12 in the series Kubernetes and everything else
Kubernetes and everything else
  1. Introduction and Application Architecture
  2. Setting up the React Application
  3. Setting up the Spring WebApplication
  4. Setting up the Python Application
  5. Container-ization of the Services
  6. Container-ization of everything else
  7. Introduction to Kubernetes
  8. Kubernetes in Practice – Pods
  9. Kubernetes in Practice – Services
  10. Kubernetes in Practice – Deployments
  11. Kubernetes and everything else in Practice
  12. Kubernetes Volumes – in Practice

Let’s continue where we left off, creating the Images for the Java and Python Applications. And then we will verify that everything works together as shown in the figure below:

Fig. 1. Microservices running in Containers

 

Containerizing the Java Application

Guess what! You learned almost everything about creating container Images! That’s why this part is extremely short.

Open the Dockerfile in sa-webapp, and you will find only two new keywords:

ENV SA_LOGIC_API_URL http://localhost:5000
…
EXPOSE 8080

The keyword ENV declares an Environment Variable inside the docker container, which will enable us to provide the URL for the Sentiment Analysis API when starting the Container.

Additionally, the keyword EXPOSE exposes a port that we want to access later on. But hey!!! We didn’t do that in the Dockerfile in SA-Frontend, Good catch! This is for documentation purposes only, also it will serve as information to the person reading the Dockerfile.

You should be familiar with building and pushing the container image, but by any difficulties read up the README.md file in sa-webapp directory.

Containerizing the Python Application

In the Dockerfile in sa-logic there are no new keywords. Now you can call yourself a Docker-Master 😉

For building and pushing the container image read up the README.md in sa-logic directory.

Testing the Docker-ized Application

Can you trust something that you didn’t test? Neither can I. Let’s give these containers a test.

  1. Run the sa-logic container and configure to listen on port 5050:
$ docker run -d -p 5050:5000 $DOCKER_ID_USER/sentiment-analysis-logic
  1. Run the sa–webapp container and configure to listen on port 8080, and additionally we need to change the port in which the python app listens by overriding the environment variable SA_LOGIC_API_URL.
$ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL='http://<container_ip or docker machine ip>:5000' $DOCKER_USER_ID/sentiment-analysis-web-app

Check out the README on how to get the container ip or docker machine ip.

  1. Run sa-frontend container:
$ docker run -d -p 80:80 $DOCKER_ID_USER/sentiment-analysis-frontend

We are done. Open your browser on url localhost:80.

Attention: If you changed the port for the sa-webapp, or if you are using docker-machine ip, you need to update App.js file in sa-frontend in the method analyzeSentence to fetch from the new IP or Port, and then you need to build, push and pull the updated image.

Why Kubernetes?

We can see that the application is working, And it is containerized, so why Kubernetes? We will investigate deeper into that in the next article, but I want to leave you a brainteaser.

  • Our Sentiment Analysis web app became a world hit and we suddenly have a million requests per minute to analyze sentiments and we experience huge load on sa-webapp and sa-logic. How can we scale the containers?
Introduction to Kubernetes >>
If you enjoyed the article, please share and comment below!
  • Zack Horvath

    Great series of articles! I had two minor corrections to suggest: On the “Testing the Dockerized Application” section, number 2 instructs the user to issue…

    $ docker run -d -p 8080:8080 $DOCKER_USER_ID/sentiment-analysis-web-app -e SA_LOGIC_API_URL=’http://localhost:5050′”

    …but if you have been following the article, the command should actually be…

    $ docker run -d -p 8080:8080 -e SA_LOGIC_API_URL=http://localhost:5050 $DOCKER_USER_OD/sentiment-analysis-webapp

    …and my reasoning is that A) it’s best practice to run all arguments before specifying the image name in Docker, and B) the service name is referred to as ‘sentiment-analysis-webapp’ the rest of the tutorials.

    Thanks for putting this together!

    • Rinor Maloku

      Thanks for the feedback Zack.
      I agree with both of your points. Will make the improvements as soon as possible 🙂

      Am glad that you liked the series!

  • Jeroen Wolff

    Hi Rinor, nice series!! But these containers are not connected well. The web-app is connecting inside in the container to http://localhost:5050 but that url is not available inside the web-app container.
    My advise is to use a network between webapp and logic and dns names to communicate like:

    $ docker network create –driver bridge backend
    $ docker run -d –name sa-logic –network backend $DOCKER_USER_ID/sentiment-analysis-logic
    $ docker run -d –name sa-webapp –network backend -p 8080:8080 -e SA_LOGIC_API_URL=’http://sa-logic:5000′ $DOCKER_USER_ID/sentiment-analysis-web-app
    $ docker run -d -p 80:80 $DOCKER_USER_ID/sentiment-analysis-frontend

    • Rinor Maloku

      Hi Jeroen, thanks 🙂

      It was my bad for not testing it on OS’s with Native docker support (this solution works on Windows and Docker with a Linux VM).
      I have updated the README on how to get the container IP for the sa-logic service, and use that one when providing the env variable.

      In hindsight using a bridge seems a great opportunity to delve deeper in docker and containers, I might do just that :).
      Thanks for the feedback and for the valuable improvements.